URL

Components

What is the URL Parser?

Paste a URL and the tool breaks it into the parts you actually care about — protocol, host, port, path, query parameters, hash. Output is JSON, so you can copy it straight into a test fixture, a debug log, or wherever else you need the components in a structured form. The parser follows the WHATWG URL Standard, which is what every modern browser uses internally.

Why a parser? Because reading a long URL with five percent-encoded query parameters and a hash fragment is painful. The browser already knows how to do this through the URL API, but you don't have a quick paste-and-see surface for it. This is that. Query parameters get decoded too — %20 becomes a space, %5B becomes [, repeated keys turn into an array — same behaviour as URLSearchParams.

Everything runs in your browser. No upload, no server, no logs. URL parsing is deterministic — there is no AI, no guessing, just the same algorithm RFC 3986 defined and the WHATWG spec refined.

How to Use the URL Parser

Three steps. Each one matches a button on this page.

Paste a URL or Load the Sample

Drop a URL into the left panel. Click Sample to load a realistic example with percent-encoding, repeated query keys, and a hash fragment. Example URL:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2#summary

Anything the URL constructor accepts works — including <code>file://</code>, <code>mailto:</code>, custom schemes, IPv6 hosts, and userinfo (<code>user:pass@host</code>).

Read the Components

The right panel shows the parsed URL as JSON: protocol, host, port, pathname, pathSegments (the path split into an array), searchParams (decoded key-value pairs, with arrays for repeated keys), and hash. Updates as you type.

Copy or Download

Click Copy to send the JSON to your clipboard, or Download to save it as a .json file. Minify compacts the JSON onto one line if you need it for a log line. Use Clear on the input panel to start over.

When You'd Actually Use This

Debugging redirects and analytics URLs

A URL with twelve query parameters from an ad-tracking redirect is unreadable in the address bar. Paste it here to see the parameters one per line, decoded, with the destination url param fully unwrapped. Pairs well with stripping trackers in our URL Cleaner (when it ships).

Inspecting webhook and OAuth callback URLs

OAuth callbacks and webhook payloads cram state into the query string. Splitting it out makes it obvious whether the state token is missing, the code got truncated, or the redirect_uri is encoded twice. RFC 6749 requires those params and this surfaces all of them at once.

Building test fixtures

When you're writing tests against a URL, you usually want it as a structured object, not a string. Paste the URL, copy the JSON, drop it into your fixture file. Saves you from typing out protocol: 'https:' by hand for the fifth time today.

Sanity-checking customer support tickets

"It broke when I clicked this link" — the link is 400 characters long with double-encoded slashes. Parser shows you exactly what the browser would see, including whether %252F means a literal %2F or a path separator that got encoded twice on the way through a proxy.

Common Questions

Does this work on relative URLs?

No — the URL constructor needs an absolute URL (with a protocol like https:// or file://). For relative URLs, prepend a base like https://example.com first, then strip it from the result. The WHATWG spec describes the two-argument form (new URL(relative, base)) used internally by browsers.

How does it handle repeated query keys?

Repeated keys collapse into an array. So ?tag=red&tag=blue becomes "tag": ["red", "blue"] in the output. This matches how most server frameworks (Express, FastAPI, ASP.NET) parse query strings.

What about array bracket notation like ?items[]=1&items[]=2?

The parser treats the brackets as part of the key — so you'll see "items[]": ["1", "2"]. That's honest to the bytes on the wire. If you need a framework-specific decoder (PHP, Rails, qs.js), do the post-processing on the parsed output.

Are credentials in URLs (user:pass@host) safe to paste here?

Parsing happens entirely in your browser — the URL never leaves your machine. That said, putting credentials in a URL is generally discouraged (RFC 3986 §3.2.1 notes the security risks), and most browsers strip them silently. If you do paste one, the username and password fields will appear in the output.

Can it handle internationalized domain names (IDNs)?

The browser's URL constructor handles IDN domains, but the output may show the Punycode form (xn--...) rather than the Unicode form. That's how the URL would actually be sent over the wire. If you need to convert between the two, a dedicated Punycode tool will land in this section soon.

Why is the output called "Components" instead of "JSON"?

It is JSON — but the framing matters. The output is the URL's parts, structured. If you treat the page as "URL → JSON converter," you miss the point: the value is the breakdown, not the format.

Other URL & JSON Tools

Parsing is one operation. Here's what else pairs naturally with it: