URL Parser

Break a URL into protocol, host, path, and query parameters.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Parses a URL into its parts — protocol, host, port, path, each query parameter and the fragment — as a URL inspector rather than a guess at where one ends, so a long link stops being one unreadable string.

How to use it

1Type or paste a URL; leave the scheme off and https:// is assumed.
2Read the Breakdown list, then the Normalized URL box above it if the two differ.
3Scan the Query Parameters table — one row per parameter, repeats included.

Example

Input: https://user:pw@example.com:8080/docs/page?q=hello&lang=en#top
Output: protocol https · username user · password pw · hostname example.com · port 8080 · pathname /docs/page · hash top, then a table reading q = hello and lang = en

Remove :8080 and the port row reads 443 (default) in grey, marking it as implied by the scheme rather than typed.

What happens to your data

The work is one call to the browser's URL constructor and a read of its searchParams, which means the address is taken apart without ever being requested — no fetch, no preview, no favicon lookup, so the host in the bar never learns you looked at it. Everything sits in a single useMemo recomputed per keystroke, so there is no history list and a reload leaves the field blank.

Last updated August 2026

A link arrives four hundred characters long — a redirect wrapped inside another redirect, a dozen tracking parameters, an encoded destination somewhere in the middle — and you want one thing from it: where it actually points, or which parameter carries the value an API keeps rejecting. Reading that off the address bar is a job for a machine: the punctuation separating the parts is the same punctuation that turns up inside them.

Settle first what you are asking. If the question is structural — which piece is the host, what is in the query, was that port typed or assumed — taking the address apart answers it exactly. If it is whether a link is safe to open, structure only gets you part of the way: you can see where an address points without going there, but nothing in the shape of a URL says what waits at the other end.

Then there is encoding. Query values are stored percent-encoded and read back decoded, so what you read is the value your server hands to your code, not the text as it sits in the address — right for chasing a mismatch, wrong for copying back into a link.

The common mistake is treating a fragment as though it travelled with the request. Everything after the hash stays in the browser and is never sent, so a token put there appears in no server log — and never reaches the endpoint you expected.

How it works

Toolvore hands the string you type to the browser's own URL constructor and reads the fields it produces, so the answer matches what your browser would do with the same link. Anything without a scheme has https:// put in front of it, unless it begins with mailto, tel, data, javascript or urn, which pass through untouched. The constructor is not passive: it lowercases the scheme and host, resolves dot segments in the path, converts a non-ASCII hostname to punycode and fills an empty path with a slash, which is why the normalised address can differ from what you pasted. It is weakest in what it does not lay out: no row for the raw query string, none for the host with its port attached, so an encoded parameter value has to be lifted out by hand. Only that address carries a copy button, and a string that will not parse gets one line saying so, with nothing about which character caused it.

Common use cases

Finding the real destination inside a wrapped redirect
Checking which parameters an OAuth redirect URI carries
Reading the utm tags on a campaign link
Confirming whether a port was typed or assumed
Pulling one value out of a long link in a bug report
Spotting a session token sitting in a shared URL

Frequently asked questions

What are the different parts of a URL called?＋

The names come from the specification and from habit, and they do not quite agree. The scheme is the part before the colon — https, mailto, ftp. What follows the slashes is the authority: user information, the host, then an optional port. Then comes the path, the query introduced by the first question mark, and the fragment after the hash. Browser APIs use their own vocabulary: protocol keeps its trailing colon, hostname is the name alone while host includes the port, and search is the query string with its question mark. The breakdown here follows the browser's names.

What is the difference between the query string and the fragment?＋

Both hang off the end of an address, but only one leaves your machine. The query string — everything from the first question mark up to the hash — is part of the request, so it reaches the server and lands in access logs and usually in analytics. The fragment, everything after the hash, is never sent at all. It was meant to point at a position inside a document already fetched, and single-page applications borrowed it for routing state. That is why older OAuth flows returned tokens after the hash: the credential stayed out of server logs.

Why do URLs contain %20 and other percent signs?＋

Percent-encoding is how an address carries a character that would otherwise read as punctuation. Each byte becomes a percent sign and two hex digits, so a space is %20, a slash inside a value is %2F, and an ampersand belonging to your data rather than to the separators is %26. The rule people miss is that you encode values, not whole addresses: push an entire URL through an encoder and the separators get encoded too. Text outside ASCII is converted to UTF-8 first, so one accented letter becomes two percent groups.

Why does a plus sign in a URL turn into a space?＋

Two conventions share the same syntax. Form submissions use application/x-www-form-urlencoded, which writes a space as a plus rather than as %20, and query strings are conventionally read back under those rules. A parameter written as a=1+2 comes back as 1 2, and a base64 value carrying plus signs loses them the same way. The query table here reads values through the browser's searchParams, which follows that convention, so what you see is very likely what your server sees too. Where a plus must survive as a plus, write it as %2B.

Can a URL have the same parameter twice?＋

Yes, and nothing in the standard says what a repeat means. Writing tag=red&tag=blue is perfectly legal, and each framework decides for itself: some hand your code a list, some keep the first value, some keep the last, and PHP wants square brackets on the name before it treats a parameter as an array. Because of that spread, a link that behaves against one backend can quietly drop a value against another. The table here gives every occurrence its own row instead of collapsing them, so you can count how many times a name genuinely appears.

Is it safe to paste a URL that contains a token or a password?＋

URLs are frequently the secret rather than a pointer to one — a password reset link, a signed download link, an invitation with no login behind it. Pulling an address apart needs no network access, and none happens here, since the work is done on text inside the tab you already have open. What is worth watching is your own screen. Credentials written before the host get their own rows, decoded and unmasked, so a screenshot of the breakdown gives away more than the raw link did. Strip them before it reaches a ticket.

Why does my URL come back looking different from the one I typed?＋

Two reasons, and both are the browser rather than a rewrite. An address with no scheme has https:// added before parsing, so example.com/page comes back with a scheme in front of it. Then normalisation runs: scheme and host are lowercased, dot segments in the path are resolved, an empty path becomes a single slash, and a hostname with non-ASCII characters is converted to its punycode form. A port matching the scheme's own default disappears from the address, though it still shows in the breakdown, marked as the default rather than as something you typed.

How can I tell where a link really goes before I click it?＋

Read from the first colon-slash-slash to the next slash, then take the last two labels — that is the registered domain, the only part identifying who controls the address. Everything to its left is a subdomain the same owner chose, so a host reading paypal.com.secure-login.example belongs to example, not to PayPal. Two tricks rely on being read too fast: an @ inside the authority makes everything before it user information, so a long trustworthy-looking name can sit ahead of the real host, and a hostname in another script can render as letters that pass for Latin. Both surface once the address is split into fields.