Skip to content
Lizely

URL Parser

Break an absolute HTTP or HTTPS URL into normalized, credential-safe components and ordered query parameters locally.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Paste one absolute HTTP or HTTPS URL without a username or password and review the input character count.
  2. 2.Parse it and inspect the normalized components, serialized filename, and ordered decoded query parameters.
  3. 3.Review potentially sensitive query or hash data, then copy the complete parsed JSON if appropriate.

About URL Parser

URL Parser breaks one absolute HTTP or HTTPS URL into its browser-normalized components. Paste a URL, select Parse URL, inspect the normalized URL, origin, protocol, host, hostname, port, pathname, query string, hash, filename, and ordered query parameters, then copy the complete parsed JSON. Parsing, display, and copying happen in the current browser tab. The URL is not uploaded to Lizely and no request is sent to the pasted address.

The tool uses the browser's native URL constructor without supplying a base URL. That choice makes the absolute-URL boundary explicit. A path such as /docs/page, a scheme-relative reference such as //example.com/path, and a bare domain such as example.com are rejected rather than being resolved against the current Lizely page. The input must independently identify its scheme and host according to the WHATWG URL parser.

Only http: and https: are accepted after parsing. javascript:, data:, file:, ftp:, blob:, mailto:, and other schemes are rejected even when the browser URL API can parse them. This focused boundary avoids presenting unlike URL types as if they shared an HTTP origin, host, port, path, and query model. The parser is an inspector, not a link opener, fetcher, redirect tester, safety scanner, or reachability check. It never navigates to the supplied URL.

URLs containing a nonempty username or password are rejected before any result is constructed. The tool does not support or redact userinfo because even a partially masked output could accidentally preserve a sensitive username, reveal password length, or be copied into logs. A URL such as https://user:[email protected] therefore produces a credentials error and no parsed fields. Query strings and fragments can also contain application secrets; those are displayed because they are requested URL components, so review them before copying or sharing output.

The normalized URL is the URL API href serialization, not necessarily the exact characters originally typed. Scheme and host casing normalize, a missing root path becomes a slash, internationalized hostnames serialize to their ASCII domain form, and a default port is removed. For example, explicit port 443 on HTTPS produces an empty port field and a host without :443. A non-default port such as 8080 remains in host and also appears separately in port. The origin combines normalized scheme, hostname, and effective non-default port.

Internationalized domain names are passed through the browser's host parser. The hostname field deliberately shows the normalized ASCII form, such as xn--r8jz45g.xn--zckzah, rather than claiming a separate Unicode-display conversion. This is useful for comparing what the browser will serialize, but it is not a homograph warning, domain reputation result, registration lookup, DNS answer, or proof of ownership. Bracketed IPv6 hosts retain their bracketed hostname serialization, while host adds a non-default port when present.

Pathname stays in serialized URL form. Percent-encoded path bytes such as %20 and %2E are not decoded into display characters by this tool. The filename is the final serialized pathname segment after the last slash. A pathname ending in a slash has an empty filename. The filename is not inferred from a query parameter, Content-Disposition header, redirect, or network response because no request occurs. A percent-encoded final segment remains percent encoded.

The search field includes its leading question mark when present, and hash includes its leading number sign. Query parameters are also exposed as an ordered array from URLSearchParams. Names and values follow URLSearchParams decoding behavior: percent escapes are decoded and plus signs become spaces. Repeated names remain repeated entries in their original order. A key without equals and a key with an explicit empty value both have an empty decoded value. The tool does not collapse these entries into an object, because doing so could silently overwrite duplicates.

Input is limited to exactly 8,192 UTF-16 code units. Complete formatted JSON output is limited independently to 50,000 code units, and query parameters are limited to exactly 200 entries. Exact boundaries are accepted and the next unit or entry is rejected. No input, path, query entry, or output is silently sliced, sampled, or skipped. ASCII control characters are rejected before URL construction so the browser cannot silently strip a newline or tab from pasted text. Ordinary URL normalization remains visible through the normalized href.

The output JSON contains the same displayed fields plus an array of query parameter name and value objects. It is intended for inspection and handoff, not as a guarantee that another programming language uses identical URL parsing rules. The WHATWG parser is the authority for this browser tool. Differences from legacy parsers, regular expressions, server frameworks, operating-system APIs, or RFC-only parsers can be meaningful, especially around hosts, backslashes, percent encoding, and special schemes.

Editing input immediately removes the old result, error, query list, summary, output, and clipboard status. Running again starts from a cleared state, so a failed URL never leaves an earlier successful result visible. Clipboard writing is asynchronous and generation guarded. If input changes while permission is pending, the old copy promise cannot publish a misleading Copied status. The status timer is canceled on replacement and unmount, while denied clipboard access leaves the full JSON available for manual selection.

Use URL Parser to debug application links, inspect default-port normalization, understand an IDN's browser hostname, audit repeated parameters, or separate path, query, and fragment text. Do not use it to validate that a site exists, determine whether a link is malicious, reveal a redirect destination, decode arbitrary binary percent sequences, verify TLS, test DNS, remove tracking parameters, or authorize navigation. For structured text work, use JSON Formatter or JSON Validator. Use HTTP Status Codes as a reference and UTM Link Builder when constructing reviewed campaign links.

Methodology & sources

Reject empty input, more than 8,192 UTF-16 code units, ASCII controls, surrounding whitespace, raw backslashes, or any input not beginning with a case-insensitive literal http:// or https:// prefix. Construct URL without a base, require normalized protocol http: or https:, and reject any nonempty username or password before building output. Read href, origin, protocol, host, hostname, port, pathname, search, and hash directly from the URL object. Define filename as the final serialized path segment unless pathname ends in slash. Enumerate URLSearchParams into an ordered array without deduplicating; reject more than 200 entries. Serialize all fields as two-space JSON, reject invalid or above-50,000-code-unit output, and never truncate. Editing clears old result and errors; a clipboard generation, mounted guard, and timer cleanup prevent stale copy status.

Frequently asked questions

Can URL Parser handle relative URLs?
No. It deliberately calls the URL constructor without a base, so paths, scheme-relative references, and bare domains are rejected instead of being resolved against the current page.
What happens to URLs containing a username or password?
They are rejected before output. The tool does not display or partially mask URL credentials, preventing a password or identifying username from entering the result.
Why is an internationalized hostname shown with xn-- labels?
The hostname field shows the browser URL API's normalized ASCII serialization. The tool does not perform a separate Unicode display or homograph-safety analysis.
Are percent-encoded paths and query parameters decoded the same way?
No. Pathname and filename remain serialized with percent escapes, while query names and values follow URLSearchParams decoding, including plus-to-space behavior.

Related tools

Developer Tools guides

View all