URL parser
Break a URL into its parts, decode the query string, and see what is actually in it — including the tracking parameters.
Every part, broken out
Scheme, host, port, user, path, path segments, query parameters and fragment — each shown separately, with the percent-escapes decoded so %20 reads as a space and %E2%9C%93 as a tick. You can turn the decoding off to see exactly what is on the wire, which is what you want when debugging a signature or an encoding bug.
A URL with no scheme is the commonest thing people paste, so example.com/path is parsed on the assumption of https:// and told about, rather than refused.
The tracking parameters, named
Most long URLs are long because of parameters that record where you came from rather than what you asked for: utm_source, fbclid, gclid, igshid, mc_eid and around forty others.
They are marked in the table and a cleaned URL is offered without them. That is worth having for two reasons. The obvious one is length — a shareable link instead of a paragraph. The less obvious one is that some of these identify you specifically: mc_eid in a Mailchimp link is your subscriber ID, so forwarding that link forwards your identity along with it, and a click from anyone you sent it to is recorded as a click from you.
Punycode, and why it matters
A domain with non-ASCII characters is stored in an ASCII form beginning xn--. The two forms look nothing like each other, and that gap is the entire mechanism behind lookalike domains — a name that reads like a familiar brand in the address bar but is a different registration using characters from another alphabet.
When a host is punycoded it is called out, so you can look at it properly rather than trusting the rendered form.
A password in a URL is a bad idea, and it is flagged
The https://user:password@host form is legal and still supported. It is also a way of guaranteeing that the password ends up in browser history, in server access logs, in every proxy along the way, and in the Referer header sent to the next site you visit. If one is present it is masked and the problem is stated.
Sorting the parameters
Useful for one specific job: comparing two URLs that ought to be equivalent. Query parameters have no defined order, so two URLs with the same parameters in a different sequence are the same request and look completely different. Sorting both makes the actual difference visible.
The fragment never leaves the browser
Everything after the # is handled entirely by the browser and is not sent to the server. Worth knowing in both directions: it is a safe place to put UI state, and a useless place to look for a value your server needs.
It runs in this page
URLs carry session tokens, password reset links, signed download URLs and internal hostnames. Pasting one into a site that sends it somewhere is how a single-use link gets used by somebody else. This one does not.
Common questions
Why is my URL so long?
Almost always tracking parameters — utm_*, fbclid, gclid and the rest. They are marked here and a cleaned version is offered.
Is it safe to share a link with utm parameters?
Length aside, some of them identify you personally. mc_eid in a Mailchimp link is your subscriber ID, so a click from anyone you forward it to is recorded as a click from you.
What does xn-- in a domain mean?
It is punycode — a domain with non-ASCII characters stored in ASCII form. It is flagged here because that gap between the stored and displayed name is how lookalike domains work.
Why does the fragment not reach my server?
By design. Everything after the # is handled by the browser and never sent. Good for UI state, useless for anything the server needs.
Can I put a password in a URL?
It is legal and it is a bad idea. It ends up in browser history, server logs, proxy logs and the Referer header. It is masked and flagged here.
Why would I sort the parameters?
To compare two URLs that should be equivalent. Parameter order is not defined, so the same request can look completely different until both are sorted.