RFC 3986 vs WHATWG URL Living Standard — which does the tool use?

WHATWG URL Living Standard, because that's what the browser's native URL constructor implements. The two specs differ in subtle but important ways: RFC 3986 (Berners-Lee, Fielding & Masinter, January 2005, Internet Standard STD 66) defines URI generic syntax with strict ABNF rules and treats malformed input as a hard error. WHATWG URL Living Standard (url.spec.whatwg.org, continuously updated) defines a parser optimised for real-world web compatibility — it accepts inputs that violate RFC 3986 (unencoded characters, redundant slashes, missing schemes) and applies normalisation rules drawn from browser behaviour. For a parser that produces the same result as your browser would, WHATWG is correct; for strict protocol-level validation (e.g., generating canonical URIs in HTTP headers), RFC 3986 is more appropriate.

What about fragments (#hash) and Single Page Application routes?

The fragment is parsed and displayed separately. Modern Single Page Applications historically used fragments for client-side routing (e.g., #/users/123) because fragments don't trigger server requests — the entire URL state lives client-side. HTML5 History API and now the more modern Navigation API have shifted SPAs toward path-based routing, but fragments are still relevant for hash-based routes, deep-linking to page sections, and OAuth implicit-flow tokens. The tool extracts the fragment exactly as the browser would expose it via `URL.hash` (including the initial `#`).

What is URLPattern and when would I use it instead of URL parsing?

URLPattern (WICG draft, urlpattern.spec.whatwg.org) is a complementary API for matching URLs against pattern strings — think of it as path-to-regexp built into the browser. It shipped stable in Chromium 95 / Edge 95 (October 2021); Chrome 117 (August 2023) extended ServiceWorker Static Routing API integration; Safari support was announced at WWDC 2025; Firefox is in development. Use cases: routing in service workers, URL matching for compression-dictionary-transport, and replacing custom regex routing in front-end frameworks. URL parsing (this tool) extracts components from a single URL; URLPattern matches a URL against a pattern like `/users/:id/posts/:postId?` to extract named parameters. They complement rather than replace each other.

URL Parser Online Free

Q: Does the tool decode percent-encoded characters and IRIs?

Yes. Query parameter values are percent-decoded for display so you can read the original text — `name=Jos%C3%A9` becomes `name=José`. The full URL is shown unchanged at the top so you can see the encoded form. For IRIs (Internationalized Resource Identifiers, RFC 3987 Duerst & Suignard, January 2005), Unicode characters in paths and query strings are accepted directly; the WHATWG parser handles the IRI-to-URI mapping internally. For internationalised domain names (IDN — café.com), the host is shown in both Unicode form and Punycode (xn--caf-dma.com per RFC 5891 Klensin, August 2010, IDNA2008), since DNS resolves only ASCII-encoded forms.

Q: Can the tool handle malformed URLs?

The tool uses the browser's native URL parser, which follows the WHATWG specification. WHATWG explicitly handles common malformed inputs (missing schemes prepended with http://, redundant slashes collapsed, unencoded characters percent-encoded) rather than throwing. For inputs the parser truly cannot handle (e.g., empty strings, non-string types, fundamentally invalid scheme syntax), it raises a TypeError with a clear message identifying which component failed. Pasting a free-form text snippet may produce unexpected results because WHATWG aggressively interprets ambiguous inputs as URLs — for stricter validation use RFC 3986 ABNF tooling.

URL Parser — WHATWG Living Standard, IRI, Punycode & URLPattern

URL parsing has two reference specifications: RFC 3986 (Berners-Lee, Fielding & Masinter, January 2005, Internet Standard STD 66) defines URI generic syntax with strict ABNF rules — scheme, authority, path, query, fragment — treating malformed input as a hard error. The WHATWG URL Living Standard (url.spec.whatwg.org, continuously updated) defines a parser optimised for browser compatibility — it accepts inputs that violate RFC 3986 and applies normalisation rules drawn from real-world web behaviour. Browsers implement WHATWG, not RFC 3986. Internationalisation adds two more layers: RFC 3987 (Duerst & Suignard, January 2005) defines IRIs (Internationalized Resource Identifiers), allowing Unicode in URI components; RFC 5890–5891 (Klensin, August 2010, IDNA2008) define how internationalised domain names map to Punycode (xn-- prefix) for DNS resolution. This tool uses the browser's native URL constructor (WHATWG-aligned), decomposes any URL into its components, decodes percent-encoded values for display, and shows IDN hostnames in both Unicode and Punycode forms.

How to use the URL parser

Paste any URL into the input box — full URLs with query strings, fragments, ports, IRI Unicode characters, and IDN hostnames all work.
The tool decomposes the URL via the browser's URL constructor (WHATWG-aligned) into protocol, host, port, path, query parameters and fragment.
Review each component in its own field. Query parameters are listed individually with percent-decoded values; IDN hostnames show both Unicode (café.com) and Punycode (xn--caf-dma.com) forms.
Copy any part you need — useful for debugging redirects, building API calls, auditing tracking parameters, or extracting Punycode for DNS lookups.

Common use cases

Debugging a redirect chain where each hop attaches or mutates query parameters — see exactly which utm_* tracking params persist across hops.
Extracting the Punycode form (xn--...) of an internationalised domain to feed into DNS or WHOIS tools that require ASCII input.
Auditing percent-encoded query values for security review — decoding tokens, OAuth state parameters, and signed payloads.
Pulling the exact host and port from a non-HTTP URL (ssh://, ftp://, ws://, custom schemes) to feed into a different tool that needs structured input.

Frequently asked questions

RFC 3986 vs WHATWG URL Living Standard — which does this tool use?

WHATWG (the browser's native URL constructor). RFC 3986 (January 2005, STD 66) defines strict ABNF syntax and treats malformed input as error; WHATWG (url.spec.whatwg.org) handles real-world web inputs gracefully — collapses redundant slashes, percent-encodes unencoded characters, lowercases scheme/host. Same result your browser produces.

Does the tool decode percent-encoded characters and IRIs?

Yes. Query values are percent-decoded — `name=Jos%C3%A9` becomes `name=José`. IRIs (RFC 3987 Duerst & Suignard, January 2005) with Unicode in paths/queries are handled via UTF-8 percent-encoding. IDN hostnames (café.com) display in both Unicode and Punycode (xn--caf-dma.com per RFC 5891 IDNA2008).

What about fragments (#hash) and SPA routes?

Fragment parsed and displayed separately. SPAs historically used fragments (#/users/123) for client-side routing because fragments don't trigger server requests. Modern SPAs use HTML5 History API + path routing; fragments still relevant for hash routes, deep-linking to sections, and OAuth implicit-flow tokens.

Can the tool handle malformed URLs?

WHATWG explicitly handles common malformed inputs (collapses redundant slashes, percent-encodes characters) rather than throwing. For inputs the parser truly can't handle (empty strings, invalid scheme syntax), TypeError raised with clear message identifying the failed component. Free-form text may be aggressively interpreted as URL — use RFC 3986 ABNF tooling for stricter validation.

What is URLPattern and when would I use it?

URLPattern (WICG draft) is a complementary API for matching URLs against patterns — path-to-regexp built into the browser. Shipped stable in Chromium 95 / Edge 95 (October 2021); Chrome 117 (August 2023) extended ServiceWorker Static Routing API integration; Safari support announced WWDC 2025; Firefox in development. Use cases: service worker routing, framework router replacement, compression-dictionary-transport. Match `/users/:id/posts/:postId?` against URLs to extract named params.

RFC 3986 vs WHATWG — and why your browser's parser may surprise you

RFC 3986 (January 2005) is the IETF Internet Standard for URI generic syntax. It uses formal ABNF grammar to define what a valid URI looks like: scheme `://` authority `/` path `?` query `#` fragment. Inputs that violate the grammar are errors — RFC 3986 doesn't try to recover, it rejects. WHATWG URL Living Standard takes the opposite approach: real-world URLs in HTML attributes, JavaScript, and HTTP headers don't always follow RFC 3986, so the WHATWG parser was designed to handle them gracefully. Common WHATWG behaviours that diverge from RFC 3986: missing schemes are not auto-prepended (the input must already contain a scheme to be a valid URL); redundant slashes in paths are collapsed; unencoded characters in query strings are percent-encoded automatically; uppercase scheme and host are lowercased. For internationalisation, RFC 3987 (IRI) extends URIs to include Unicode characters directly — IRIs map to URIs by percent-encoding the UTF-8 bytes. Internationalised domain names use a separate mechanism: RFC 5891 (IDNA2008) defines the lookup protocol that converts Unicode hostnames (café.com) to ASCII Punycode (xn--caf-dma.com) per RFC 3492 — DNS itself only resolves ASCII. URLPattern (WICG draft, urlpattern.spec.whatwg.org) is a complementary API that shipped stable in Chromium 95 / Edge 95 (October 2021) for matching URLs against pattern strings; Chrome 117 (August 2023) extended ServiceWorker Static Routing API integration — useful for service worker routing and replacing path-to-regexp libraries.

Protocol, hostname, port, path, query, fragment decomposition (WHATWG-aligned)
Percent-decoding of query parameter values for display
IDN hostname display in Unicode + Punycode (RFC 5891 IDNA2008)
IRI support per RFC 3987 (Unicode in URI components)
Query parameter listed individually with key/value pairs
Built on browser's native URL API — no external dependencies, no server round-trip

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (7)

Berners-Lee, T., Fielding, R., & Masinter, L. (2005). Uniform Resource Identifier (URI): Generic Syntax. RFC 3986, IETF (January 2005 — Internet Standard STD 66; scheme/authority/path/query/fragment).
Duerst, M., & Suignard, M. (2005). Internationalized Resource Identifiers (IRIs). RFC 3987, IETF (January 2005 — Unicode/ISO 10646 in URIs; complement to RFC 3986).
Klensin, J. (2010). Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. RFC 5890, IETF (August 2010 — IDNA2008 base definitions).
Klensin, J. (2010). Internationalized Domain Names in Applications (IDNA): Protocol. RFC 5891, IETF (August 2010 — IDNA2008 lookup/registration; Punycode xn-- prefix; updates and replaces RFC 3490 IDNA2003).
Costello, A. (2003). Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). RFC 3492, IETF (March 2003 — encoding scheme used by IDNA2008 to map Unicode hostnames to ASCII xn-- form).
WHATWG (live). URL Living Standard. url.spec.whatwg.org — browser-aligned parser; differs from RFC 3986 in error handling and percent-encoding.
WICG / W3C Web Performance WG (2024). URLPattern. WICG draft (urlpattern.spec.whatwg.org); shipped stable in Chromium 95 / Edge 95 (October 2021); Chrome 117 (August 2023) extended ServiceWorker Static Routing API integration; Safari support announced WWDC 2025; Firefox in development.

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

By Marco B. · Last verified June 2026 — runs in your browser