To parse URL parameters in JavaScript, create a URL object for an absolute HTTP or HTTPS address and read its searchParams, which exposes decoded names and values while preserving repeated entries in order. The URL Parser tool applies that browser-native model in a visual workflow: paste one URL, select Parse URL, and inspect the normalized address, its component fields, the final filename, and an ordered array of query parameters. It is useful when you need to understand how a browser serializes a link before using its values in application code, hand a structured result to another workflow, or diagnose an unexpected query string. The parser distinguishes the pathname from the search and hash, so “page,” “?id=42,” and “#section” do not get confused. It also shows normalization that a hand-written split can hide, including a missing root slash, host casing, default-port removal, and ASCII serialization of an internationalized hostname. All parsing and display occur in the current browser tab; the pasted address is not uploaded to Lizely, and no request is sent to it. URL Parser does not open, fetch, test, or validate the destination.
The Parts a JavaScript URL Parser Exposes
JavaScript’s browser URL interface separates an HTTP(S) address into fields instead of treating it as one opaque string. URL Parser reads those fields from the browser’s native URL constructor, then reads query entries through URLSearchParams. That division makes it possible to inspect the route, query string, fragment, and final path segment independently.
The normalized URL is the URL API’s href serialization, so it can differ from the exact characters entered. The main components and their parsing behavior are:
| Field | What it represents | Important detail |
|---|---|---|
| Normalized URL | The complete href serialization | May differ from the characters originally pasted |
| Origin | Scheme, hostname, and non-default port | The default port is omitted |
| Protocol | The parsed scheme | Only http: and https: are accepted |
| Host | Hostname plus a non-default port | Includes a port only when it is not the scheme default |
| Hostname | The normalized host name | Internationalized hosts use ASCII serialization |
| Port | The non-default port, when present | A default port is removed rather than retained |
| Pathname | The serialized URL path | Percent-encoded path bytes are not decoded for display |
| Search | The serialized query string | Includes its leading question mark when present |
| Hash | The URL fragment | Includes its leading number sign |
| Filename | The final serialized pathname segment | Empty when the pathname ends with a slash |
An explicit 443 on an HTTPS URL produces an empty port field and a host without “:443,” while 8080 remains in the host and appears separately in port. A missing root path becomes “/.” Internationalized hostnames serialize to ASCII labels such as “xn--r8jz45g.xn--zckzah,” and bracketed IPv6 hostname serialization is retained.
Parse One URL with the Tool
The workflow stays deliberately narrow: one absolute HTTP or HTTPS address per parse. That boundary prevents a path or bare domain from being silently resolved against the page displaying the tool.
- Paste one absolute URL. It must start with a case-insensitive http:// or https:// prefix and independently identify its scheme and host. Paths such as /docs/page, scheme-relative references such as //example.com/path, and bare domains such as example.com are rejected. Do not include a username or password. Review the displayed input character count before parsing.
- Select Parse URL. Inspect the normalized URL, origin, protocol, host, hostname, port, pathname, search, hash, filename, and ordered query parameters. The parameter list exposes each name and value separately instead of collapsing repeated names into one object property.
- Review the result before copying it. Check query and hash content for tokens, personal information, or other sensitive data. When the output is appropriate to share, copy the complete parsed JSON. If clipboard access is denied, the full JSON remains available for manual selection.
Editing the input immediately removes the previous result, error, query list, summary, output, and clipboard status. A new parse therefore starts from a cleared state, and a failed URL never leaves an earlier successful result visible.
See What Browser Normalization Changes
Normalization matters when debugging application links because it reveals the form exposed by a browser URL object. Compare the pasted address with the normalized URL and check these points:
- Scheme and host casing are normalized, while a missing root path becomes a slash.
- Default ports are removed; a non-default port remains available in both the host and port fields.
- An internationalized hostname is shown in its normalized ASCII form. The result is not a homograph warning or Unicode safety analysis.
- Percent-encoded path bytes such as “%20” and “%2E” remain encoded in the displayed pathname. The filename is the final serialized segment, not a value inferred from a query parameter, header, redirect, or network response.
Because URL Parser never requests the destination, there is no response from which it could infer a different filename, redirect target, or content disposition. The filename shown is purely the path-based result defined by the browser parser.
Read Query Decoding and Repeated Names
The search field and the parameter array represent the query in two useful ways. The search field contains the serialized query string, including its leading question mark. The array follows the decoding behavior documented for URLSearchParams: percent escapes in names and values are decoded, and plus signs become spaces.
| Representation | Decoding behavior | Edge behavior |
|---|---|---|
| Search | Remains serialized | Keeps the complete query representation |
| Parameter name and value | Decoded by URLSearchParams | Plus signs become spaces |
| Pathname and filename | Remain serialized | Percent escapes are not decoded for display |
Repeated names remain repeated entries in their original order, which prevents an earlier value from disappearing. A key without an equals sign and a key with an explicit empty value both display an empty decoded value. URL Parser deliberately keeps the parameters as an ordered array rather than converting them to an object, because object assignment can silently overwrite duplicate names.
Respect Input Limits and Sensitive Data
- Input is limited to exactly 8,192 UTF-16 code units. Exactly 200 query-parameter entries are also accepted. Complete formatted JSON output is independently limited to exactly 50,000 code units. The exact boundaries are accepted, while the next unit or entry is rejected.
- No input, path, query entry, or output is silently sliced, sampled, or skipped. Empty input, surrounding whitespace, raw backslashes, ASCII control characters, and input that does not begin with the required HTTP or HTTPS prefix are rejected before parsing.
- Only HTTP and HTTPS are accepted after URL construction. Schemes such as javascript:, data:, file:, ftp:, blob:, and mailto: are rejected even when the browser URL API can represent them.
- A URL containing a nonempty username or password is rejected before any result is constructed. No parsed fields are produced, and the tool does not support or partially mask userinfo.
- Query strings and fragments can contain application secrets. They remain visible because they are requested URL components, so review them before copying or sharing the 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.
Map the Result to JavaScript URL APIs
URL Parser is intended for inspection and handoff, not as a guarantee that another programming language uses identical parsing rules. The WHATWG browser parser is authoritative for this tool, and differences from legacy parsers, regular expressions, server frameworks, operating-system APIs, or RFC-only parsers can be meaningful around hosts, backslashes, percent encoding, and special schemes.
In browser JavaScript, const parsed = new URL(input) creates the same browser-style component model for an absolute URL. The expression parsed.searchParams.get("id") returns the first value for a name or null when it is absent. The method parsed.searchParams.getAll("tag") collects repeated values, while parsed.searchParams.entries() provides ordered name-value pairs. These methods follow URLSearchParams rules instead of relying on a fragile manual split.
When transferring the tool’s JSON into application code, preserve the query parameters as an array of name-value objects if duplicates or order matter. Converting that array directly into a plain object can overwrite earlier entries. Calling new URL(input) without a base also matches the tool’s absolute-only boundary; adding a base URL enables relative resolution, but that is a different workflow from URL Parser.
Separate Parsing from Link Verification
URL Parser is an inspector, not a link opener, fetcher, redirect tester, safety scanner, or reachability check. It never navigates to the supplied URL.
- It does not show whether a site exists, whether a link is malicious, where a server redirects, or whether the destination uses a valid TLS configuration.
- It does not perform DNS lookups, domain reputation checks, registration searches, ownership verification, or homograph analysis.
- It does not decode arbitrary binary percent sequences, remove tracking parameters, or authorize navigation.
For debugging application links, inspecting default-port normalization, understanding a browser-normalized internationalized hostname, auditing repeated parameters, or separating path, query, and fragment text, the parsed result provides a precise browser-level view. Review sensitive fields, preserve duplicate entries, and copy the complete JSON only when it is ready for the next step.