URL Parser

Split any URL into protocol, host, port, path, query parameters, and fragment. Query params shown as a key/value table.

URL Parser

Split any URL into protocol, host, port, path, query parameters, and fragment. Query params shown as a key/value table.

Debugging a redirect, a webhook callback, or an API link? Paste the URL and see every part broken out: scheme, hostname, port, path, each query parameter decoded into a key/value table, and the fragment. Scheme-less input is assumed to be https:// and flagged as such.

Splits any URL into protocol, host, port, path, query parameters, and fragment — handy for debugging links, webhooks, and API callbacks.

How to use this calculator

  1. Paste a URL — the https:// scheme is optional.
  2. Click Parse (or press Enter).
  3. Read the parts table and the query-parameter breakdown.

Worked example

Parsing https://shop.example.com:8443/products?category=books&sort=price#results — verified by running the parser — gives protocol https:, host shop.example.com, port 8443, path /products, two query parameters (category=books, sort=price), and fragment results.

Frequently Asked Questions

What are the parts of a URL?

Scheme (https), host (example.com), port (:8080), path (/docs/page), query (?q=1&lang=en), and fragment (#top). This tool splits them out and lists every query parameter as a decoded key/value row, so you can see exactly what data a link carries.

Why did it add https:// to my URL?

You pasted a scheme-less address like example.com/page. Browsers do the same thing when you type that into the address bar. The tool assumes https:// — the modern default — and tells you it did, so there's no silent guessing.

What are query parameters for?

Key/value pairs after the ? that pass data to the page or API: search terms, pagination, tracking tags like utm_source, and API options. The parser decodes percent-encoding for you, so %20 displays as a space and you see the real values.

What's the fragment (#) used for?

The part after # never reaches the server — the browser keeps it. It's used for in-page anchors (#top jumps to an element) and by single-page apps for client-side routing. That's why it's listed separately from the parts the server actually receives.

Can it handle unusual URLs?

It uses the same URL parser your browser does, so ports, IPv6 hosts, userinfo, and percent-encoded characters are handled correctly. Genuinely malformed input gets a plain-language error instead of a crash or a silently wrong answer.