Node.js parses absolute HTTP and HTTPS URLs through the global URL class, which implements the WHATWG URL Standard — the same specification the URL constructor in every modern browser follows. Passing a string such as new URL("https://example.com/docs/page?id=42#top") returns an object with normalized protocol, host, hostname, port, pathname, search, and hash fields, plus a paired URLSearchParams view of the query string. Because Node.js 10+ exposes WHATWG URL as a global, there is no require('url') step for the modern API, and the output you get in a terminal matches what document.createElement('a') produces in a browser. That parity is what makes a browser-side inspector like URL Parser a fast way to prototype and audit parsing before writing a script. The tool runs the browser's URL constructor with no base URL, normalizes scheme and host casing, strips the default port, and serializes percent-encoded path bytes without decoding them, so every field you see is exactly what the WHATWG parser would hand back in a Node.js script.
Why the Node.js URL Class Matches the Browser
A Node.js developer can expect a parsed URL object to behave the same as one created in Chrome, Firefox, or Safari because both environments target the WHATWG URL Standard rather than a separate legacy implementation. The fields host, hostname, and port therefore follow one definition regardless of where the code runs, and percent-encoded bytes are normalized through the same parser. The standard is published as the WHATWG URL specification and documented on the MDN URL reference page, which is also the canonical reference for any Node.js developer who wants to look up edge cases such as backslash handling, IDN serialization, or default-port stripping. When you paste a URL into a browser inspector built on the same constructor, the result reflects what your Node.js code would print, so you can iterate on the input rather than re-running a script each time and waiting for a console.log to flush.
Parts of a URL That the Parser Surfaces
The tool exposes every component a typical Node.js or browser script would read from a parsed URL object, plus a small number of derived fields that are useful for handoff and auditing. The complete list, taken from the WHATWG URL object plus the URL Parser implementation, looks like this:
| Field | What it contains |
|---|---|
| href | Fully serialized URL after WHATWG normalization |
| origin | Scheme, hostname, and effective non-default port |
| protocol | Always ends with a colon, e.g. https: |
| host | Hostname plus port when the port is non-default |
| hostname | ASCII host, with internationalized names shown as xn-- labels |
| port | Empty when the port is the default for the scheme, otherwise the explicit number |
| pathname | Serialized path with percent escapes preserved |
| search | Query string including the leading ?, may be empty |
| hash | Fragment including the leading #, may be empty |
| filename | Final path segment after the last slash; empty when the path ends in / |
| query parameters | Ordered array from URLSearchParams, with repeated names preserved |
The single rule that catches most developers off guard is default-port stripping: an explicit :443 on an HTTPS URL produces an empty port field and a host without the suffix, because the WHATWG parser treats it as the scheme default. A non-default port such as :8080 stays in host and also appears separately in port, so the two fields are not redundant in that case. Bracketed IPv6 hosts keep their bracketed hostname serialization, while host adds a non-default port when one is present.
Parse a URL in Three Steps
- Paste one absolute HTTP or HTTPS URL into the input box. The character count updates as you type, and the input is capped at exactly 8,192 UTF-16 code units — the next character is rejected, not sliced.
- Choose Parse URL. The tool runs the browser's URL constructor without a base, validates that the scheme is http or https, and rejects any nonempty username or password before producing a result. The output panel then shows the normalized href, origin, protocol, host, hostname, port, pathname, search, hash, filename, and the ordered query parameters decoded by URLSearchParams.
- Review the query string and hash for any secrets, then copy the complete parsed JSON if it is safe to share. Editing the input clears the previous result, error, query list, summary, output, and clipboard status, so a failed URL never leaves an earlier success visible.
What the Parser Rejects Before It Builds a Result
The tool is deliberately strict so it never presents unlike inputs as if they shared the same model. The following inputs are refused at the boundary and produce an error instead of a parsed object:
- Empty input
- Input longer than 8,192 UTF-16 code units
- ASCII control characters, including pasted newlines and tabs that some editors strip silently
- Surrounding whitespace before or after the URL
- Raw backslashes, which some legacy libraries treat as path separators
- Anything that does not begin with a case-insensitive literal http:// or https:// prefix
- Schemes other than http and https, even when the browser URL API can parse them — this includes javascript:, data:, file:, ftp:, blob:, and mailto:
- Relative paths such as /docs/page, scheme-relative references such as //example.com/path, and bare domains such as example.com, because the constructor is called without a base URL and these would otherwise be resolved against the current page
- Any URL containing a nonempty username or password — for example, https://user:[email protected] returns a credentials error and no parsed fields, because the tool never displays or partially masks userinfo
- Query strings with more than 200 entries, formatted JSON output longer than 50,000 code units, or any input that would push the result past those exact limits
These limits mean a single failed URL does not leave residue. Editing the input removes the old result, error, query list, summary, output, and clipboard status, and a fresh run starts from a cleared state. Clipboard writing is generation-guarded, so an in-flight copy promise cannot publish a misleading "Copied" status after the input has changed.
When URL Parser Saves You a Node.js Round Trip
Several debugging tasks that normally require a Node.js REPL or a quick script become a single paste and click:
- Confirm default-port normalization. Paste https://api.example.com:443/v1 and confirm the port field is empty and host no longer contains :443.
- Inspect an IDN hostname. Paste a Unicode internationalized domain and read the hostname field to see the browser's xn-- serialization, which is the form your Node.js code will compare against.
- Audit repeated query parameters. A URL such as ?tag=a&tag=b produces an ordered array with both entries preserved. The parser does not collapse duplicates into an object, so a key like tag with two values is visible exactly as the server will receive it.
- Separate path, query, and fragment text. The pathname, search, and hash fields are displayed independently, with their leading ? and # preserved, which is useful when reconstructing a URL by hand.
- Spot percent-encoding differences. Pathname and filename keep percent escapes such as %20 and %2E, while query names and values are decoded by URLSearchParams, including plus-to-space conversion. Confirming this split by eye is faster than reading a spec.
There are several jobs the tool is not built for. It does not navigate to the URL, fetch it, follow redirects, scan for malware, test DNS, validate TLS, decode arbitrary binary percent sequences, or remove tracking parameters. Treat it as an inspector of the input string, not a check on the destination. For adjacent tasks, parsing query strings into JSON covers the wider query-handling workflow, and the MDN URL reference documents every field the tool reads.
Because Node.js's URL class and the browser's URL constructor both implement the WHATWG URL Standard, the parsed fields shown by URL Parser are the same fields your new URL(...) call would produce in a script. That makes the tool a useful pre-flight check before you commit a parser to a codebase, and a quick way to demonstrate URL parsing to a teammate without opening a terminal.