URL Parser

Paste a URL and see its parts: scheme, host, port, path, query parameters, fragment and userinfo — raw and percent-decoded, side by side.

The URL is split apart locally by your browser's parser. Nothing is fetched and nothing leaves your device.

ComponentValue
Paste a URL to see its anatomy.

How It Works

Everything here defers to your browser's own WHATWG URL parser — the same implementation that powers real requests — so the anatomy you see matches what the network stack actually understands. It splits the string by the grammar of RFC 3986: scheme ":" [ "//" authority ] path [ "?" query ] [ "#" fragment ], with the authority itself holding optional userinfo@, the host, and :port.

The component grammar
Parsing walks the URL left to right: everything up to the first : is the scheme; an authority follows only when // comes next; the query is everything between the first ? and any #; the fragment is what follows the #. Repeated query keys are kept as separate rows rather than collapsed, because order and duplication can both be meaningful.
Why browsers are more forgiving than the spec
The URL constructor trims stray spaces, lower-cases schemes and hosts, auto-escapes illegal characters in paths, and accepts missing default ports — a leniency browsers standardised so that typing example.com works. That is also why an absolute URL needs a scheme: without one there is nothing to anchor the parse, so the tool offers to prefix https:// for you.
Query goes to the server, fragment never does
The part after # is a client-side marker: browsers send the path and query to the server but keep the fragment local for scroll targets and single-page routing. If a value must reach the backend it belongs in the query; anything you place after # is honestly only as private as a bookmark you can share.

Frequently Asked Questions

Do mailto: or data: URLs parse here?

Partly. The browser's URL object accepts any scheme, so mailto:[email protected] splits into protocol mailto: and the address landing in the path slot — but there is no host, port, query or fragment to show, and that is correct: those components simply do not exist for such schemes. javascript: and data: URLs likewise parse as scheme plus opaque path, and this parser will never execute what they contain.

Why do spaces come back as %20 after I edit and copy?

Because percent-encoding is not decoration but the grammar of URLs: a raw space is not a legal URL byte, so every serialiser rewrites it as %20 (or + inside old form queries). The Raw column always shows the transport form, the Decoded column shows what it means, and copying either gives you a string that survives the trip back into a browser unchanged.

Where did the brackets around my IPv6 host go?

They are still there — IPv6 addresses contain colons, which would otherwise collide with the port delimiter, so RFC 3986 wraps them in brackets: http://[2001:db8::1]:8080/. The URL object strips the brackets when handing you the hostname, and this tool notes the host as bracketed for display honesty. Re-add brackets when pasting the bare address back into a URL.

Does the tool decode percent sequences twice?

No — exactly one decoding pass, because guessing about double-encoding breaks legitimate data. But if a value still contains a %XX sequence after that single pass, the Notes column flags it as possibly double-encoded; decode again on purpose if that matches what you expect, since a real %25 in the original data will look like this too.

Is anything uploaded to a server?

No. The URL is split apart by the browser's own WHATWG URL parser running locally, in your tab. Nothing is fetched, no request is sent to the URL you paste, and no analytics touch the components — including any credentials embedded in the address.