Skip to content
ToolBoxGeniehome

URL Parser

Developer Tools · Added

Paste a URL and this breaks it into the components the WHATWG standard defines — scheme, credentials, host, port, path, query and fragment — decodes the query string into a readable table, and points out what is unusual: repeated parameters, credentials in the userinfo, a plus that will decode differently on different servers, or a link long enough to be truncated somewhere downstream.

Parsed here in your browser with the platform's own URL implementation. Nothing is requested and nothing is sent anywhere.

Result

Normalised URL

https://www.example.com:8443/shop/blue%20widgets/?q=large+widget&sort=price&utm_source=newsletter&utm_medium=email&page=2#reviews

Scheme
https
Host
www.example.com

3 labels

Port
8443

explicit

Path segments
2
Query parameters
5
Length
129

characters

Components

protocol
https:
username
—
password
—
hostname
www.example.com
port
8443
origin
https://www.example.com:8443
pathname
/shop/blue%20widgets/
search
?q=large+widget&sort=price&utm_source=newsletter&utm_medium=email&page=2
hash
#reviews

Path, decoded

/shop/blue widgets

Query parameters, decoded

KeyValueNotes
qlarge widgetwas encoded
sortprice—
utm_sourcenewslettertracking
utm_mediumemailtracking
page2—

Without the 2 tracking parameters

https://www.example.com:8443/shop/blue%20widgets/?q=large+widget&sort=price&page=2#reviews

These parameters identify the campaign that sent you, not the page you are looking at. Removing them almost always leaves the same page — but a few sites do route on them, so check before sharing something important.

Parameters as JSON

{
  "q": "large widget",
  "sort": "price",
  "utm_source": "newsletter",
  "utm_medium": "email",
  "page": "2"
}

Worth knowing

  • There is a + in the query string. In form-encoded data it means a space, but the URL standard treats it as a literal plus in the path — which is why servers disagree about it. Percent-encode it as %2B when a plus is what you mean.

The parsing is the browser's own WHATWG URL implementation, which is the same code that decides what a link in the address bar means. A regular expression cannot reproduce it: percent-encoding sets differ per component, hosts go through IDNA, IPv4 has shorthand forms, and dot segments in the path have to be resolved.

How to use the url parser

  1. 1Paste a URL. It is parsed as you type, using your browser's own URL implementation.
  2. 2Read the component table, and the decoded query parameters underneath it.
  3. 3Copy the parameters as JSON, or take the tracking-free version of the URL.
  4. 4Check the findings at the bottom — that is where the encoding and security notes appear.

Examples

A tracked marketing link

Input
A URL carrying utm_source, utm_medium and a click identifier
Result
The same URL with the tracking parameters removed, ready to copy

Those parameters identify the campaign that sent you, not the page you are looking at.

The plus-sign trap

Input
?q=large+widget
Result
Decoded as a space, with a note that servers disagree about this

In form encoding a plus is a space; in the URL standard's path rules it is a literal plus. Percent-encode it as %2B when you mean one.

A redundant port

Input
https://example.com:443/
Result
Flagged as the default for the scheme, and dropped from the normalised form

Which is why the normalised URL can differ from what you pasted.

About the url parser

The parts of a URL, and which ones people get wrong

A full URL is scheme, optional userinfo, host, optional port, path, optional query and optional fragment. The parts that cause trouble are rarely the obvious ones. Userinfo — the user:password@ form before the host — still parses, but modern browsers strip it before making a request, and anything in it lands in proxy and server logs in clear text. Anyone who finds credentials there in a codebase has found a leak.

The fragment is the other commonly misunderstood part. Everything after the hash is never sent to the server at all: it is handled entirely in the browser, which is why single-page applications historically used it for routing and why analytics that only sees server logs is blind to it.

The query string is not really a URL construct either. The standard says only that it is text between the question mark and the fragment; the key=value&key=value convention is a convention, one that HTML form submission established and everything else copied. That is why servers disagree about duplicate keys and about what a plus sign means.

Encoding, and the two ways it goes wrong

Percent-encoding is per-component, which is the source of most confusion. A character that must be escaped in a query value may be perfectly legal in a path, and the sets differ again for the fragment and the hostname. Reaching for a single escape function for the whole URL is how a working link becomes a broken one — encodeURIComponent applied to an entire URL escapes the slashes and the colon.

Double encoding is the other failure. A URL that has been escaped twice contains %2520 where it should contain %20, because the percent sign of the first encoding got encoded again. It usually happens when a value passes through two layers that each helpfully escape it. The tell is a %25 followed by two hex digits, and this tool flags it, because the symptom at the far end — a filename with a literal %20 in it — points nowhere near the cause.

How long is too long

There is no limit in the URL standard, and there are limits everywhere else. The 2,000-character figure that everyone treats as safe traces back to old versions of Internet Explorer, which capped at 2,083, and it stuck because nothing since has been lower. Above it you are relying on every intermediary agreeing: web servers have their own request-line limits, CDNs and proxies impose theirs, and analytics tools and databases often truncate silently rather than erroring.

Silent truncation is what makes long URLs worth flagging. A link that is too long does not usually fail visibly — it works in testing and then loses its last few parameters somewhere in production, which is a considerably harder bug to find than a 414 response would have been.

Frequently asked questions

Why does the normalised URL differ from what I pasted?
Because parsing a URL is also normalising it. The scheme and host are lower-cased, dot segments in the path are resolved, a default port for the scheme is dropped, characters that must be encoded are encoded, and a non-ASCII hostname is converted to punycode. All of that is what the browser does before making a request, so the normalised form is what would actually go on the wire — and comparing it against your input is often how you find the character that was wrong.
Why not just use a regular expression?
Because URL parsing looks like a regex problem and is not. The WHATWG algorithm has different percent-encoding sets for each component, IDNA processing for hosts, several shorthand forms for IPv4 literals, backslash normalisation, dot-segment resolution and scheme-relative references. Every regex that circulates for this gets some of those wrong. This uses the platform's own implementation — the same code that decides what a link in the address bar means.
What happens with repeated query parameters?
They are all shown, in order, and flagged. There is no standard for which one a server should use: PHP keeps the last, Rails collects them into an array, some frameworks take the first, and a few reject the request. If a URL you are debugging has a duplicate key, that ambiguity is a real candidate for the bug — and it is why the table preserves order rather than collapsing keys into an object.
Is it safe to remove the tracking parameters?
Almost always, and it makes a shared link far shorter and less revealing about where you got it. The exception is that a small number of sites do route or personalise on parameters that look like tracking, so if you are sharing something that has to work exactly — a support link, a checkout, an invitation — open the cleaned version once before passing it on. The tool shows both so you can compare.
Does anything get sent anywhere?
No. The URL is parsed in your browser and no request is made to it — this tool never fetches the address, checks whether it resolves, or reports what it saw. That also means it cannot tell you whether a link is safe to visit. It describes the structure of the text you pasted, which is a different question from whether the site at the other end is trustworthy.

Related tools