URL Parser
Parse any URL into protocol, host, path, and query parameters. Paste a link, see each part clearly, then copy values for debugging.
URL Parser
SIMILAR TOOLS
What the URL Parser tool does
This takes a web address and breaks it into its separate parts, so you can see exactly what it is made of. Paste a URL in, press the button, and the tool lays out the pieces: the protocol, the host, the port, the path, the query values, and the fragment. It is a different kind of tool from encoding or decoding. Instead of changing the address, it takes it apart so you can read its structure.
It runs in your browser, so nothing you enter is uploaded.
How to use it
- Enter a URL. Paste a complete web address, including the http:// or https:// at the front.
- Press the button. The address is split into its parts and shown to you, each labelled.
The anatomy of a URL
A web address looks like one long string, but it is really several labelled pieces joined together, each marked off by its own punctuation. Take this example:
https://www.example.com:8080/blog/post?id=42&sort=new#comments
Reading it left to right, the parts are these. The protocol is https, the rule for how to talk to the server, sitting before the ://. The host is www.example.com, the name of the machine you are reaching. The port is 8080, the specific door on that machine, written after the colon; most addresses leave it out and use the default for the protocol. The path is /blog/post, which points to the particular page or resource on the host. The query is everything after the question mark, id=42&sort=new, carrying extra values. And the fragment is comments, after the hash, usually a spot to jump to within the page. The parser pulls each of these out and names it for you.
The query string, broken into pieces
The query is often the busiest part, and the tool does something useful with it: instead of handing you the whole id=42&sort=new in one lump, it splits it into the individual pairs it contains. The query is built from key-and-value pairs joined by ampersands, so this one is really two separate facts, id is 42 and sort is new, and the parser lists them that way. That makes it much easier to see what a long, crowded query is actually saying. One thing to keep in mind is that values in a query are often percent-encoded, so if a value comes out full of codes like %20, the URL Decoder tool will turn it back into plain text.
It uses the browser's own URL engine
The tool does not guess at the structure with its own rules. It hands the address to the browser's built-in URL engine, the very same one the browser uses every time you follow a link, and reads back the parts it identifies. That means it splits an address exactly the way a browser would, which is as authoritative as it gets. The one thing it needs in return is a complete, valid address, including the protocol at the front. Paste www.example.com on its own and there is not enough there for the engine to work with; paste https://www.example.com and it has what it needs.
Questions people ask
What parts does it show?
The protocol, the host, the port, the path, the query broken into its individual values, and the fragment. Together these are the pieces that make up a web address.
Why does it need the http:// at the front?
Because a valid URL starts with its protocol, and the parser needs a complete address to work from. Without it, there is not enough structure to split apart reliably.
What is the fragment, the part after the hash?
It is usually a marker for a place within the page, like a particular heading, so the browser can jump straight to it. It is part of the address but is handled by the browser rather than sent to the server.
What is the difference between the host and the path?
The host is which machine you are reaching, like www.example.com. The path is which page or resource on that machine, like /blog/post. The host gets you to the server, the path finds the thing on it.
References
- WHATWG. URL Standard (the specification behind the browser's URL engine). https://url.spec.whatwg.org/
- Berners-Lee, T., Fielding, R., Masinter, L. (2005). RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. Internet Engineering Task Force (IETF). https://www.rfc-editor.org/rfc/rfc3986
Bhabin Khadka is a software engineer and graduate student at the University of New England with experience in backend development and scalable systems. He has a particular interest in file systems and the kinds of technical utilities that depend on dependable handling of structured data. At Eon Tools, he reviews file and document tools, as well as encode and decode tools.