WHATWG URL parsing
The tool uses the same parser the browser uses, which means the results match what your application code will see when it constructs a URL object at runtime.
URL Parser breaks any URL into its standard parts — protocol, host, port, pathname, search, hash, query parameters — and shows them side by side so you can debug redirects, validate UTM strings, and inspect production links without writing a parsing script.
URL Parser is a free, browser-based tool that uses the WHATWG URL specification (the same standard browsers and Node.js implement) to break a URL into its component parts. Paste a link and the tool extracts protocol, username, password, hostname, port, pathname, query string, and fragment, then lists every key/value pair from the query string in a clean table you can copy from individually.
URL Parser is the fastest way to answer questions like "what does this redirect actually go to," "is the utm_content value being double-encoded," and "what port and path does this internal service URL resolve to." Because parsing runs locally in your browser, you can inspect customer-facing tracking links, internal service URLs, and confidential pre-launch addresses without uploading them anywhere.
Typical users are marketers verifying UTM tags before sending a campaign, developers debugging redirect chains and OAuth callback URLs, QA engineers comparing two URLs to find a subtle difference, and support staff helping users understand where a suspicious link points before they click it.
The tool uses the same parser the browser uses, which means the results match what your application code will see when it constructs a URL object at runtime.
Every URL part — protocol, username, password, hostname, port, pathname, search, hash — is shown on its own row so you can read and copy each one independently.
Every key/value pair in the search string is listed in a separate row. Each row has a copy button so you can extract individual parameters without manual splitting.
You can paste a URL with or without the scheme. The tool prepends https:// when missing so you do not have to fix the input first.
The tool shows the origin alongside the host, which is useful for CORS configuration, third-party cookie debugging, and Referer header checks.
All parsing happens in your browser. Internal service URLs, customer-facing tracking links, and unannounced pre-launch addresses stay on your device.
A URL is a structured string with a fixed set of components defined by RFC 3986 and the WHATWG URL Living Standard. Reading from left to right, you see the scheme (https), an optional userinfo block (user:pass), the host and optional port, a pathname, an optional query string introduced by a question mark, and an optional fragment introduced by a hash. Each of these parts has its own escaping rules, which is why a single misplaced percent sign can break parsing in surprising ways.
URL Parser walks every level of this structure for you. The host is split from the port; the username and password are decoded; the query string is broken into individual key/value pairs while preserving the original order; and the fragment is extracted intact. This is the same work your application code does when it constructs a URL object — surfacing it visually lets you debug subtle problems without writing a one-off script.
A few normalisations are worth knowing about. The parser lowercases the scheme and host, removes the default port for the scheme (so https://example.com:443 and https://example.com are shown identically), and percent-decodes parts that allow it. If you need a non-normalised view, copy the raw input from the field instead of the parsed "Full URL" row.
Input
https://example.com/landing?utm_source=newsletter&utm_medium=email#section-3Output
protocol: https:, hostname: example.com, pathname: /landing, utm_source=newsletter, utm_medium=email, hash: #section-3For marketing sends, paste the final URL into URL Parser before scheduling the campaign. Confirm utm_source, utm_medium, utm_campaign, and any custom parameters look exactly as expected.
Many OAuth failures come from a redirect_uri that differs from the registered value by a trailing slash, casing, or query order. Use URL Parser to compare both forms side by side.
CORS rules are scoped to origins (scheme + host + port). The origin row in URL Parser is the exact string to compare against your allow-list, and the safest copy/paste target for configuration.
If a query value looks unexpectedly long or contains %25 (a percent sign that has been encoded again), upstream code is encoding twice. Decode once with URL Decode and re-encode at the right layer.
For URLs from untrusted sources, parse them in URL Parser first, inspect each part, and decide whether to open the URL at all. Even when you choose to open it, a sandboxed browser profile reduces risk.
Look for illegal characters, missing colons, or unescaped spaces. URL-encode dynamic values before assembling the URL.
Normalisation is intentional — the browser lowercases the scheme and host, removes default ports, and percent-decodes safe characters. Copy from the input field if you need the raw form.
The query parameter table lists every key and value separately, so a missing equals sign, swapped ampersand, or double-encoded value is immediately visible.
Parse the registered URL and the actual URL side by side. URL Parser surfaces the trailing slash, port, or casing difference that the provider would otherwise complain about cryptically.
Copy the hostname row directly into a firewall rule, CORS configuration, or analytics filter without manual extraction.
Parsing the URL first lets you read where it actually points before clicking. The full URL row shows the canonical form, which is sometimes different from what the user-visible link text suggests.
Drop both URLs through URL Parser and compare components row by row. The difference is usually a single missing parameter, encoded space, or port.
The address bar shows the URL as one string and copies it verbatim. URL Parser breaks it into every standard component, making it easy to inspect specific parts (port, query parameters, fragment) without manual splitting.
Yes, for any scheme the WHATWG URL parser recognises (ftp, ws, mailto, file, etc.). Paste the URL and read the parts. Note that some schemes have less structure than http/https.
No. All parsing happens in your browser using the native WHATWG URL parser. Internal service URLs and unannounced pre-launch links never leave the device.
Browser URL parsing normalises the URL — lowercasing the scheme and host, removing the default port, and percent-decoding some characters. The result is the canonical form your application code will see at runtime.
The most common causes are illegal characters in the host, unescaped spaces, missing colons, or a non-existent scheme. Use URL Encode on individual components and reassemble before retrying.
Yes. Every parameter has its own row with a copy button that puts "key=value" on your clipboard. The component rows above the query table have their own copy buttons too.
Yes. The WHATWG URL parser keeps every occurrence of a duplicate key. The table shows each one on its own row so you can confirm intentional duplicates versus accidental ones.
Parse each intermediate URL in a redirect chain to confirm the protocol, host, path, and query parameters at every step. Subtle changes between hops are often the cause of mysterious tracking or login bugs.
URL Parser is the fastest way to see every part of a URL — useful for verifying campaign tags, debugging OAuth redirects, and inspecting links that look harmless on the surface.