URL Parser in your browser, no signup

A URL packs six distinct pieces of information into one string, and when it is long enough to wrap across three lines nobody can read it accurately. Breaking it apart makes each piece visible: the protocol, the hostname, the port, the path, every query parameter separately, and the fragment after the hash. Two of those are worth understanding properly. Query parameters are where most debugging happens - a tracking-laden campaign URL can carry a dozen, percent-encoded into unreadability, and seeing them as a list immediately answers what a link is actually passing. The fragment is the part people misunderstand: everything after # is never sent to the server at all. It is handled entirely by the browser, which is why single-page apps once used it for routing and why putting anything in it that the server needs simply does not work. Parsing runs in your browser.

You should not have to open an IDE to format a snippet from Slack, tidy a JSON blob, or check a hash. Paste it here, copy the result, move on.

URL Parser is a good fit when debugging why an API call is not receiving the parameters you expect.

In plain English

URL Parser is built around a few practical wins, not a long feature list:

• Turns an unreadable URL into a labelled breakdown in one step.
• Decodes percent-encoded parameter values so you can read what is actually being passed.
• Lists each query parameter separately rather than as one string.
• Runs in your browser, so URLs containing tokens are never transmitted.
• No account and no limit.

How to run it

1. Paste your URL. A tracking link, an API endpoint, a redirect - anything long enough to be hard to read.
2. Read the components. Protocol, host, port, path, query parameters and fragment shown separately.
3. Check the query parameters individually. Percent-encoded values are decoded, which is usually where the answer is.
4. Note what the fragment contains. Anything after # never reaches the server - useful to know when debugging.

Real situations

• Debugging why an API call is not receiving the parameters you expect.
• Checking where a shortened or redirect link actually points.
• Reading a campaign URL cluttered with UTM parameters.
• Inspecting an OAuth callback URL during authentication work.
• Confirming a link before clicking it.

Small habits that help

• Look at the parameters first. That is where the vast majority of URL bugs live.
• Remember the fragment never reaches the server - if the backend needs a value, it belongs in the query string.
• Watch for double-encoded values (%2520 rather than %20), which indicate the URL was encoded twice.
• Repeated parameter names are legal and handled differently by different frameworks, which is a subtle source of bugs.
• To build rather than inspect a URL, the URL Encoder handles escaping values correctly.

Skip these

• Expecting the fragment to be available server-side. It is browser-only, always.
• Assuming a parameter is missing when it is actually double-encoded and therefore unrecognised.
• Editing a URL by hand and breaking the escaping, particularly around & and =.
• Trusting a shortened link without checking where it resolves to.
• Ignoring the port when debugging a local or non-standard endpoint.

Does anything leave your device?

URL Parser runs in your browser. The file or text you paste stays on your device. There is no account, and nothing is stored on a ToolBox server for this job.

Related tools worth opening next

If this is one step in a longer job, these usually come after it:

• URL Encoder - Encode and decode URLs
• HTTP Header Viewer - Fetch a URL and inspect its response headers
• API Tester - Send HTTP requests to any REST API and inspect the response - works with public endpoints and your localhost dev server

FAQ

What parts of a URL does it break down?

Typically the protocol (http/https), hostname, port (if specified), path, each individual query parameter, and the fragment/hash portion after a #.

Can I use this to build a URL, not just parse an existing one?

This tool focuses on parsing/breaking down an existing URL. If you need to construct query parameters, you can edit the parsed values and reassemble them manually based on what the tool shows you.

Does it decode URL-encoded characters in the query string?

Yes - percent-encoded values such as %20 are decoded so you can read what is actually being passed rather than the escaped form.

Why does the server not see the part after the # in my URL?

Because fragments are never transmitted. The browser strips everything from the hash onwards before making the request and handles it locally. Anything the server needs must go in the path or query string.

What does %2520 in a URL mean?

Double encoding. %20 is an encoded space; encoding that string again turns the % itself into %25, giving %2520. It usually means a URL was encoded at two different layers, and the fix is to decode once before re-encoding.

Is my URL sent anywhere?

No. Parsing happens in your browser, which matters because URLs frequently carry access tokens, session identifiers and personal data in their parameters.

Open the URL Parser when you are ready. It is free, and you do not need an account.