API & Web

URL Parser

Breaks a URL into its parts with the browser’s own parser, so the answer matches what a browser would do.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste one URL for the full breakdown, or several for a comparison table.
  2. Select Parse.
  3. Check the Origin row when you are chasing a CORS or same-origin problem — that is the exact string the browser compares.
  4. Compare the Normalised row with what you pasted. Any difference is the parser telling you your URL was not quite what you thought.

What url parser does

URLs are parsed here by the same WHATWG parser your browser uses, not by a regular expression. That matters because the two disagree in exactly the cases that cause trouble — a host with a trailing dot, an empty port, a path with encoded slashes. If this page says a URL resolves somewhere, a browser will resolve it the same way.

Paste one URL and you get the full breakdown, including the origin that same-origin checks and CORS actually compare, and the normalised form after the parser has finished with it. Paste several and you get a comparison table instead. Credentials embedded in a URL are called out, because they travel in plain text and end up in server logs and browser history.

Frequently asked questions

https:// is assumed and the assumption is reported in the result. A string like example.com/path is not technically a URL — it has no scheme, and a strict parser rejects it — but assuming https and saying so is more useful than refusing, and marking the guess means you are never misled by it.

Because an origin is only the scheme, host and port. That triple is what the same-origin policy and CORS compare, which is why two pages on the same domain but different ports are cross-origin to each other, and why http and https versions of the same site are too.

No. Nothing here makes a request. The parsing runs in your browser against the text you pasted, so putting an internal or a signed URL in is safe — no traffic goes to it and nothing is uploaded anywhere.

Because credentials in a URL are sent in clear text within the request, and the whole URL is then stored in browser history, in server access logs and in any proxy in between. A URL carrying a password should be treated as a credential that needs rotating, not as a link.