URL parser

Break a URL into its parts and query parameters.

Protocol	-
Hostname	-
Port	-
Path	-
Query string	-
Hash (#)	-
User info	-
Origin	-

A tracking link arrives with a dozen chained parameters and you need to know which campaign it belongs to, or a callback URL is failing and the culprit is hiding somewhere in the query string. Reading that by eye is slow and error-prone. Paste it here and every component comes back as a labelled row.

How it works

What you get back

Parsing uses the browser's own URL engine — the same one the address bar uses — so results match how a browser would actually interpret the link.

Field	What it shows
Protocol	The scheme without the colon: `https`, `http`, `ftp`
Hostname	The domain only, with no port attached
Port	The explicit port, or `(default)` when the scheme's standard port applies
Path	Everything after the host up to the `?`, defaulting to `/`
Query string	The raw text from `?` onward, still encoded
Hash	The `#fragment`, which is never sent to the server
User info	The username in a `user:pass@host` URL. The password is masked
Origin	Protocol + host + port — the unit browsers use for same-origin rules

The query parameter table

Below the fields, each key=value pair is listed on its own row with percent-encoding decoded, so %40 shows as @ and + shows as a space. A key that appears more than once gets one row per occurrence, which makes duplicated utm_source values easy to spot.

If parsing fails

The most common cause is a missing scheme. example.com/page is not a complete URL — write https://example.com/page. Also check for spaces pasted in from an email client, which need to be encoded as %20.

Terms explained

Origin: Protocol, host and port together. Browsers compare origins to decide what counts as same-origin for cookies and CORS.
Query string: The part after ?, carrying key=value pairs joined by &. Read by the server or by client-side scripts.
Fragment (hash): The part after #. It stays in the browser and is never included in the request sent to the server.
Percent-encoding: Writing reserved characters as %XX so they survive transport. %20 is a space, %40 is @.
User info: Credentials embedded as user:pass@host. Widely discouraged, and most browsers now strip or block it.
Default port: The port implied by the scheme — 443 for https, 80 for http — when none is written in the URL.

Frequently asked questions

Why do I get "Could not parse the URL"?

Almost always a missing protocol. The parser needs an absolute URL, so add https:// in front. Stray spaces or line breaks pasted from a chat or email will also cause it.

Are the query parameter values decoded?

Yes. The table shows decoded values, so %20 appears as a space and %40 as @. Plus signs in the query string are also read as spaces, which is how form submissions encode them.

What happens when the same parameter appears twice?

Each occurrence gets its own row, in the order it appears in the URL. That makes duplicated tracking parameters easy to catch, since servers differ in whether they take the first or the last.

Is the URL I paste sent anywhere?

No. Parsing happens in your browser and nothing is transmitted, so links containing tokens or session identifiers stay on your machine. Passwords in the user info field are masked in the display as well.

Why is the fragment shown separately from the path?

Because the fragment never leaves the browser. It is used for in-page anchors and client-side routing, so it cannot be read by server logs or analytics unless a script sends it explicitly.

Query parameters