Can URL Parser handle relative URLs?

No. The tool deliberately calls the URL constructor without supplying a base, so 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 instead of being resolved against the current page.

What happens to URLs containing a username or password?

They are rejected before any result is constructed. URL Parser does not display, partially mask, or redact userinfo, so a URL such as https://user:secret@example.com produces a credentials error and no parsed fields.

Why is an internationalized hostname shown with xn-- labels?

The hostname field shows the browser URL API's normalized ASCII serialization. URL Parser does not perform a separate Unicode display or a homograph-safety analysis, The value reflects the browser URL API's normalized ASCII hostname serialization; it is not a DNS answer.

Are percent-encoded paths and query parameters decoded the same way?

No. Pathname and filename remain serialized with percent escapes such as %20 and %2E, while query names and values follow URLSearchParams decoding, where percent escapes are decoded and plus signs become spaces.

Does URL Parser navigate to or fetch the pasted URL?

No. The tool is an inspector only. It never opens the link, never sends a request, never follows redirects, and never receives DNS, TLS, or Content-Disposition information.

How to Parse a URL in Java Without Code

URL Parser is a browser-based inspector that decomposes one absolute HTTP or HTTPS URL into protocol, origin, host, hostname, port, pathname, search, hash, filename, and ordered query parameters using the WHATWG URL standard. For developers who land on this page while searching for a Java solution, the practical reality is that you do not need a JVM, a build script, or a java.net.URL import just to inspect what a link contains — the same WHATWG parser that runs inside modern browsers is exposed through a small client-side interface that executes entirely in your current tab. Paste the link, click parse, and the tool returns the normalized href, the origin, and every discrete component alongside an ordered array of query parameters. The URL is never uploaded, the request is never sent to the pasted address, and no part of the result is silently sliced or sampled. This makes the tool a quick first stop when you want to debug an application link, audit repeated parameters, or understand how a default port or internationalized hostname serializes, without compiling a single line of Java or any other server-side code.

What URL Parser Returns for an HTTP URL

URL Parser decomposes one absolute HTTP or HTTPS URL into the eleven fields most developers reach for when they debug a link. The tool reads protocol, hostname, port, host, origin, pathname, filename, search, hash, and the full href directly from the browser URL object, then enumerates the search string into an ordered array of query parameters using URLSearchParams. None of these fields are derived from a network request, so the result reflects exactly how the WHATWG URL parser serializes the input on this device. You can try URL Parser in a fresh tab and confirm the output against a link you already know.

Field	Source on the URL object	Example value for https://shop.example.com:8443/cart/index.html?ref=summer&ref=fall#coupon
protocol	URL.protocol	https:
hostname	URL.hostname	shop.example.com
port	URL.port	8443
host	URL.host	shop.example.com:8443
origin	URL.origin	https://shop.example.com:8443
pathname	URL.pathname	/cart/index.html
filename	final serialized segment	index.html
search	URL.search	?ref=summer&ref=fall
hash	URL.hash	#coupon
queryParams	URLSearchParams entries	[{name:"ref",value:"summer"},{name:"ref",value:"fall"}]

The repeated ref parameter is preserved exactly as supplied. URL Parser does not collapse it into an object, so you can see whether an analytics or A/B-testing pipeline is sending the same key twice, in what order, and with what values. That is a small but important difference from a quick String.split("&") approach in Java or a regex-based extractor that quietly overwrites duplicates.

When a Browser Inspector Beats java.net.URL

In Java, java.net.URL is built for protocol handlers and connection opening rather than quiet inspection. To extract protocol, host, port, path, query, and fragment from a string you usually instantiate the URL, reach for getProtocol(), getHost(), getPort(), getPath(), getQuery(), and getRef(), and then split the query on & by hand. That approach compiles, runs, and answers your question — but it also pulls in a JVM, your build system, and a few minutes of round trips when all you really want is to read what the link contains. A browser-based URL inspector turns the same WHATWG URL standard that the MDN URL documentation describes into a clickable surface. The result is a normalized href plus every discrete component, rendered the same way a real browser would interpret the link, without ever opening it.

Parsing a URL in Three Steps

The workflow is intentionally short. Each step is local to the active tab, so nothing leaves your machine and the parser starts from a cleared state every time you re-run it.

Paste one absolute HTTP or HTTPS URL into the input box. The URL must independently identify its scheme and host — paths, scheme-relative references, and bare domains are rejected rather than resolved against the current page. URLs that contain a nonempty username or password are also rejected at this stage so credentials never enter the output. The character count under the input is the running UTF-16 code unit length and accepts up to exactly 8,192.
Select Parse URL. The tool constructs the URL without supplying a base, requires the normalized protocol to be http: or https:, and rejects any other scheme (including javascript:, data:, file:, ftp:, blob:, and mailto:). The result panel then exposes the normalized href, origin, protocol, host, hostname, port, pathname, search, hash, filename, and the ordered decoded query parameters.
Review the query string and hash for sensitive data, then copy the complete parsed JSON to your clipboard if you want to share or store it. Editing the input immediately clears the previous result, error, query list, summary, and clipboard status, so a failed URL never leaves an earlier successful result visible.

If clipboard permission is denied, the full JSON remains available for manual selection — no fields are hidden or compressed. If you need to inspect the same URL again, just paste and re-run; the previous JSON is not cached anywhere outside the current session.

How Each Component Gets Normalized

WHATWG URL parsing is not a literal pass-through. Several characters in your input are quietly normalized so that the result reflects what the browser would actually send on the wire. The table below summarizes the rules URL Parser surfaces, each drawn directly from the MDN URL reference.

Original detail	Normalized behavior	Concrete example
Uppercase scheme	Lowercased	HTTPS://Example.COM → protocol "https:" and host lowercased
Default HTTPS port 443	Removed from host and port	https://example.com:443/ → port "" and host "example.com"
Non-default port	Kept in both host and port	https://example.com:8080/ → port "8080" and host "example.com:8080"
Internationalized hostname	Converted to ASCII (Punycode)	https://例え.jp/ → hostname "xn--r8jz45g.jp"
Empty pathname	Becomes a single slash	https://example.com → pathname "/"
Trailing-slash pathname	Filename is empty	https://example.com/docs/ → filename ""
Percent bytes in path	Preserved as-is	/docs/page%20one → pathname "/docs/page%20one"
Bracketed IPv6 host	Brackets kept, port appended	http://[2001:db8::1]:8080/ → host "[2001:db8::1]:8080"

Two of these rules are easy to miss. The hostname field shows the browser URL API's normalized ASCII serialization, which is useful for comparing what the browser will serialize. It is not a DNS answer, domain reputation result, registration lookup, proof of ownership, or homograph warning. The trailing-slash rule is also where many hand-rolled Java parsers go wrong, because they fall back on substring(lastIndexOf('/')) and silently report the literal empty string as a filename — exactly what URL Parser reports, but only because it is doing the same thing against the canonical serialized pathname, not against your raw text.

Hard Limits and Credential Rules

URL Parser is an inspector, not a fetcher. It never navigates to the URL you paste, never sends a request, and never receives a redirect, DNS answer, TLS certificate, or Content-Disposition header. The boundaries below are explicit so the tool cannot be quietly misused as a link validator or a malicious-link scanner.

The input is limited to exactly 8,192 UTF-16 code units. ASCII control characters, surrounding whitespace, and raw backslashes are rejected before the URL is constructed, so a pasted newline or stray tab cannot be silently stripped. Query parameters are limited to exactly 200 entries, and the complete formatted JSON output is independently limited to 50,000 code units. Exact boundaries are accepted; the next unit or entry is rejected. Nothing is silently sliced, sampled, or skipped.

Credential handling is the strictest rule. Any URL containing a nonempty username or password is rejected before any field is built. The tool does not display, partially mask, or redact userinfo because even a partly masked output could preserve a sensitive username, hint at password length, or be copied into logs. So https://user:[email protected] produces a credentials error and no parsed fields, even though the underlying URL API would happily parse it. Query strings and fragments can also carry application secrets, and those are surfaced because they are part of the requested URL components — review them before copying the JSON or sharing the result.

If you change the input, the old result, error, query list, summary, output, and clipboard status are cleared immediately. A re-run starts from a clean state, and a failed URL never leaves an earlier successful result visible. The clipboard write is asynchronous and generation-guarded, so a clipboard permission that resolves after you have already edited the input cannot publish a misleading "Copied" status for the previous result. If you want a deeper look at how query parameters are decoded — particularly the plus-to-space behavior — the MDN URLSearchParams reference spells out every rule the browser follows.

If you specifically want the query string turned into a structured JSON object rather than an ordered array, see the guide on parsing URL query strings into JSON. That article walks through plus signs, repeated keys, and percent-encoded values with the same browser-based approach.

For working with the JSON this inspector produces — reformatting, validating, or minifying before you paste it elsewhere — the JSON Formatter and JSON Validator both run locally in your tab. To look up the HTTP status code a real request to that URL would have returned, browse the HTTP Status Codes reference.

URL Parser is not a substitute for opening the link, checking the certificate, or resolving the DNS record. It is a deterministic WHATWG-based reader for the URL text itself, which is exactly the part you can copy into your clipboard, your bug report, or your test fixture.