WHATWG URL · Optional base · No fetch

URL Parser

Reject malformed escapes first, then break an absolute URL into normalized components or resolve a relative reference against a base. Inspect the structure without opening the address, resolving its host, or following redirects.

Parse a URLFree · No sign-up · URL and base stay local
url record
scheme   https:
host     api.example.com
pathname /v1/items
search   ?page=2

Components, not a network checkSerialization can normalize input

See the browser's URL record

Parse an absolute or relative URL online

Enter an absolute URL, or add an absolute base for a relative reference. LiveParse applies stricter text validation before the browser URL algorithm; each field accepts up to 32,768 UTF-16 code units, and parsing never requests the destination.

Loading the URL parser…

Enable JavaScript to parse and copy URL components. The URL anatomy and normalization guide remains readable below.

One string, several semantic fields

URL anatomy: scheme, authority, path, query, and fragment

A URL is more than text split on punctuation. In https://user:pass@example.com:8443/a/b?q=tea#results, the scheme is https:, the authority contains credentials, host, and port, the path is /a/b, the query is ?q=tea, and the fragment is #results. Whether a delimiter is structural depends on the parser state and scheme.

LiveParse uses the browser's WHATWG URL implementation rather than a regular expression. That matters for IPv6 brackets, internationalized domain names, backslashes in special URLs, credentials, default ports, percent escapes, relative references, and schemes with opaque paths. The WHATWG living standard aims to match interoperable browser behavior; RFC 3986 remains useful for the generic URI syntax and terminology, but the two models are not identical in every edge case.

Before invoking that implementation, LiveParse rejects stray or non-hex percent signs, percent-encoded byte sequences that are not valid UTF-8, and unpaired UTF-16 surrogates. A native URL object can preserve some malformed percent text that this tool deliberately rejects, so the result is WHATWG parsing after a stricter LiveParse input gate rather than an unrestricted wrapper around new URL().

The parser shows a normalized serialization in addition to components. Treat that result as the browser's interpretation, not a byte-preserving transform. If the exact original spelling matters for a signature, cache key, forensic record, or protocol transcript, retain the original string separately.

URLs may carry passwords, signed query values, OAuth codes, account identifiers, and private object paths. The component table redacts username and password values, and its copy actions remove URL userinfo, but the original input and non-credential components can still contain secrets. The parser stays local and does not navigate; redact the source and review copied output before sharing.

Scheme
The leading protocol label such as https:, interpreted by the URL algorithm.
Authority
Optional credentials, hostname, and port for URL types that use them.
Path
Hierarchical segments or an opaque path, depending on the scheme.
Query
Text after ?, also exposed through ordered query entries.
Fragment
Text after #; normally not sent in an HTTP request.

Relative references need context

How optional base URL resolution works

Relative inputBase URLResolved result
../images/logo.pnghttps://example.com/docs/start/https://example.com/docs/images/logo.png
?page=2https://example.com/items?sort=namehttps://example.com/items?page=2
#detailshttps://example.com/report?year=2026https://example.com/report?year=2026#details
//cdn.example.net/a.jshttps://example.com/app/https://cdn.example.net/a.js

Review how percent-encoded bytes interact with URL components →

Parse, compare, then validate in context

How to inspect a URL without opening it

  1. 1

    Keep the original string

    Preserve the source URL exactly when spelling, escaping, or evidence matters. Remove secrets from any sample that will later be shared.

  2. 2

    Add a base only when needed

    Absolute input parses on its own. For a relative path, query, fragment, or scheme-relative reference, provide the same absolute base the real application uses.

  3. 3

    Compare normalized fields

    Review host, port, pathname, ordered query entries, fragment, origin, and normalized serialization. Confirm the result in the receiving runtime before making a security decision.

Successful parsing can rewrite presentation

WHATWG URL normalization to expect

Scheme and host case

ASCII scheme and hostname letters serialize in lowercase. Path and query case are generally data and must not be normalized the same way.

Default ports

A port equal to the special scheme's default can disappear from normalized serialization, such as explicit port 443 on an HTTPS URL.

Dot path segments

. and .. segments in hierarchical URLs can be resolved during parsing, so the serialized path may not retain them.

Internationalized hosts

A Unicode hostname can serialize in its ASCII domain form. Similar-looking Unicode characters still require security review; successful IDNA processing is not a trust signal.

Parsing is deliberately narrower than validation

What this URL parser does not verify

The page creates a URL record and displays its components. It does not resolve DNS, connect to an IP address, send an HTTP request, validate a TLS certificate, follow a redirect, inspect response headers, or load remote content. A syntactically parsed hostname may not exist, and an existing destination may still be malicious.

Origin values also need careful interpretation. Some URL schemes produce an opaque origin serialized as null; the literal text null is not a hostname or proof that a page has no security context. Browser same-origin behavior depends on the complete platform rules, document creation, sandboxing, and redirects, not only a pasted string.

The 32,768-code-unit limit on each input is a LiveParse responsiveness bound. It does not define an internet-wide maximum. Browsers, proxies, CDNs, application servers, frameworks, databases, and individual protocols can enforce much smaller and different request-target limits.

Only need query parameters?

Use the focused query parser to preserve ordered entries, repeated names, and empty values under URLSearchParams form rules.

Open the Query String Parser →

Questions answered

URL parser FAQ

What does a URL parser show?

A URL parser applies a defined parsing algorithm and exposes fields such as the normalized URL, scheme, origin, host, hostname, port, path, query, fragment, and query entries. Some fields are empty or have special values for schemes that do not use an HTTP-style authority.

How can I parse a relative URL?

Provide a valid absolute base URL together with the relative reference. The WHATWG algorithm resolves paths, query text, and fragments against that base. Without a usable base, input such as ../images/logo.png has no standalone absolute URL to parse.

Why can the normalized URL differ from my input?

WHATWG parsing and serialization can lowercase an ASCII scheme or hostname, remove a default port, resolve dot path segments, encode some characters, and serialize an internationalized hostname in ASCII form. A successful parse therefore does not promise byte-for-byte preservation.

Is a URL parser the same as a URL decoder?

No. A decoder removes one selected percent-encoding layer from text. A parser interprets the entire URL structure and may preserve or normalize escapes according to each component. Decode only the layer you intend before parsing; do not recursively decode by default.

Does a successful parse prove that a URL exists or is safe?

No. Parsing only means the browser URL algorithm produced a URL record. It does not perform DNS lookup, connect to the host, follow redirects, check an HTTP status, detect phishing, scan content, or establish that the destination is trustworthy.

Is the URL or base uploaded when I use this parser?

No. Parsing and relative resolution run in the current browser tab. The page does not upload either field, navigate to the result, resolve the hostname, fetch remote content, or follow redirects. Device software and extensions remain separate privacy boundaries.

What are the URL parser input limits?

The URL field and the optional base URL field are each limited to 32,768 UTF-16 code units. These are LiveParse application limits for bounded interactive work, not universal URL-length limits for browsers, servers, proxies, or protocols.