URL Parser
Break down any URL into its components — protocol, host, port, path, query parameters, hash, and credentials.
100% private
Decompose any URL into its parts — protocol, hostname, port, pathname, query parameters (as a key-value table), and fragment. It's the fastest way to sanity-check the exact parameters a third-party API or OAuth provider will receive, without manually URL-decoding by hand. Useful for debugging OAuth, working with tracking links, and unpacking the long URLs analytics platforms generate. The parser uses the browser's native URL API; pasted URLs stay in your tab.
URL Structure
https://user:pass@hostname.com:8080/path/to/page?key=value&foo=bar#section
https://Protocoluser:pass@Authexample.comHostname:8080Port/path/pagePathname?key=valueQuery#sectionHashRuns in your browser
Next steps
URL Encoder / Decoder
RecommendedPercent-encode and decode URLs and URL components. Supports encodeURIComponent and encodeURI.
HTML Encoder / Decoder
RecommendedEncode HTML special characters to entities and decode them back.
Regex Tester
Write and test regex patterns with real-time match highlighting.
JWT Decoder
Decode JWT tokens and inspect header, payload, claims, and expiry instantly.
Runs right inside your browser tab. No uploads. Your files stay private.
What Is a URL Parser?
A Uniform Resource Locator is the address format defined by RFC 3986 (and updated by the WHATWG URL Living Standard) that identifies a resource on a network. It has a strictly defined grammar: scheme, optional userinfo, host, optional port, path, optional query, and optional fragment. This parser breaks any URL into those components and surfaces the query parameters as a key-value list.
Under the hood, this tool relies entirely on the browser's built-in URL constructor and URLSearchParams API — the WHATWG implementation that backs every modern browser, Node.js, Deno, and Bun. That implementation handles dozens of edge cases that hand-rolled parsers get wrong: IDNA punycode encoding for internationalized hostnames (例え.jp becomes xn--r8jz45g.jp), IPv6 brackets, default-port stripping, dot-segment normalization in paths, and proper handling of relative URLs against a base.
The parser tolerates inputs that omit the protocol — if you paste example.com/page?q=1 the tool prefixes https:// before constructing the URL. This matches user expectations but means you cannot use the tool to reason about scheme-less or protocol-relative URLs (//cdn.example.com/...) without explicitly supplying the base. Provide a full scheme when accuracy matters.
Query parameters are extracted via URLSearchParams.entries(), which automatically decodes form-urlencoded values (turning + back into space and resolving percent-encoded bytes). That decoding is the most common reason hand-built parsers disagree with the URL API: a value like name=John%20Doe&pet=cat%26dog requires careful handling of the ampersand in 'cat&dog' versus the ampersand that separates name and pet. URLSearchParams gets this right.
Be aware of the userinfo component (the user:pass@ part). Modern browsers warn or block embedded credentials in fetch and navigation contexts because of phishing risks (the URL https://google.com@evil.com goes to evil.com). The parser still surfaces userinfo when present so you can see what is in a URL you copied from somewhere, but you should never include credentials in URLs in your own systems — use Authorization headers instead.
The fragment (the part after #) is parsed and shown but reminded that it is client-only: browsers never send the fragment to the server in the HTTP request. Single-page applications use it for routing in hash-based routers; OAuth implicit flows historically returned access tokens in the fragment to keep them out of server logs. The query (the part after ?) is sent and gets logged, which is why you should avoid putting secrets there.
All parsing happens locally. The URL is constructed in memory, the components are read from instance properties, and nothing is fetched, looked up, or transmitted. The tool never resolves DNS, never opens the URL, and never sends what you paste to any analytics endpoint.
Common Use Cases
01
API debugging
Inspect path segments, query parameters, and embedded credentials in API URLs lifted from logs or curl commands.
02
OAuth callback analysis
Break down redirect URIs to see code, state, error, and scope parameters returned by an identity provider.
03
UTM and tracking audit
List the utm_source, utm_medium, gclid, and fbclid parameters attached to a marketing link.
04
Webhook signature troubleshooting
Verify that the path and query you receive match what the sender computed the signature against.
Frequently Asked Questions
The query is everything after the first ? and is sent to the server in the HTTP request line. The fragment is everything after #, is only available to the browser, and is never transmitted. Query is for server-routed parameters; fragment is for client-side state and anchor scrolling.
When the port matches the scheme's default (80 for http, 443 for https, 21 for ftp, 80 for ws, 443 for wss), the URL API normalizes it away. The parser surfaces this as 'default' so you know the port is implicit, not missing.
The URL constructor applies IDNA (RFC 5891) and converts internationalized labels to their punycode form. example.伊藤 becomes example.xn--zhrr96i. The parser shows the punycode form, which is what DNS actually resolves.
Because URLs allow them. ?id=1&id=2&id=3 is valid and many APIs interpret it as an array. URLSearchParams preserves order and duplicates; if your backend treats only the first or last value as authoritative, that is a backend convention, not a URL spec rule.
user:password@ in a URL is technically valid but a security anti-pattern. Browsers warn or strip them, and they leak through Referer headers and logs. The parser shows them so you know they are there; do not use them in production. Send credentials in Authorization headers instead.
Common causes: missing scheme (paste https://...), unencoded spaces or non-ASCII bytes (encode them first), or stray characters from copy-paste like a trailing parenthesis from Markdown. The URL constructor is strict by design.
Yes — data: URIs are valid URLs and the constructor accepts them. The pathname will contain the MIME type and Base64 payload; the host and search will be empty. Same goes for blob: and javascript: schemes (the latter is a known XSS vector and should never be navigated to from untrusted input).
Host is hostname plus port (example.com:8080). Origin is scheme plus host (https://example.com:8080). Origin is the unit the same-origin policy uses for cookie scoping, CORS decisions, and storage isolation; host is just the network address.
It does not, by default. If your input has no scheme, the tool prefixes https:// and parses against that. To resolve a true relative URL like /api/users against a base, you would call new URL('/api/users', 'https://example.com') in code.
No. URL parsing uses the browser's built-in URL and URLSearchParams APIs. Nothing is fetched, logged, or transmitted.
Advertisement
What's next?