URL Parser

Pull a Complicated URL Apart Without Guesswork

A URL often looks like one indivisible string until a redirect fails, an API request returns the wrong record, or a query parameter appears twice. The URL Parser separates that string into the fields exposed by the browser URL model: protocol, hostname, explicit port, pathname, fragment, credentials, origin, and query parameters. It also rebuilds the address while you edit its parameter list, making it useful for both inspection and controlled changes.

Try this exact input:

https://user:[email protected]:8080/path/to/resource?search=react&sort=desc&category=tools#section-1

The protocol is https:, the hostname is example.com, and the explicit port is 8080. The path is /path/to/resource; the hash is #section-1; and the origin is https://example.com:8080. Three query rows appear for search, sort, and category. The username and password are parsed too, although the interface masks the displayed password.

This breakdown matters because delimiters have context. A question mark starts the query, an ampersand separates query pairs, and a hash begins the fragment. The same characters can be data when percent-encoded. Reading the whole string visually is therefore less reliable than parsing it according to URL rules.

What the Parser Shows

The component cards describe different layers of an address:

• Protocol is the scheme including its trailing colon, such as https: or http:.
• Hostname is the domain or IP address without credentials or port.
• Port is only the explicitly supplied port. If none is present, the card says (default) rather than guessing a number.
• Pathname identifies the hierarchical resource path and begins with / for an HTTP URL.
• Hash / Fragment includes the leading #. Browsers usually use it client-side and do not send it in an HTTP request.
• Username and password come from URL user information before the host. Their presence is not an endorsement of embedding secrets in links.
• Origin combines scheme, host, and port as normalized by the platform URL parser.
• Query parameters are displayed as editable key/value rows in encounter order.

The “Parsed & Rebuilt URL” is a serialized result, not necessarily a byte-for-byte copy of the input. The browser may normalize details such as a missing trailing slash, percent encoding, or a default port. That normalization is helpful when comparing the semantic URL rather than its original typography.

A Practical Query-Editing Workflow

Suppose a bug report contains:

https://shop.example.test/products?category=keyboards&page=4&debug=true#results

Paste it into the input area and confirm that the pathname is /products and the fragment is #results. In the Query Parameters panel, change page from 4 to 1, remove debug, and add a row with key sort and value price. The input and rebuilt URL update as the rows change. Copy the resulting URL and reproduce the issue with a clean first-page request.

This is safer than editing punctuation in a long address. The tool reconstructs the query using URLSearchParams, so values containing spaces, ampersands, equals signs, or non-ASCII text are serialized appropriately. For example, entering key q and value red & blue produces an encoded parameter rather than treating the ampersand as a separator.

Empty keys are omitted during reconstruction. Empty values are retained when they belong to a non-empty key, so a row such as preview= remains meaningful. Removing every row clears the query entirely. Use the per-field copy controls when you need only a hostname, origin, pathname, or one key=value pair; use Copy URL when you need the complete rebuilt address.

URLs Without a Scheme

For convenience, this parser accepts common host-like inputs without a protocol. Entering:

localhost:3000/api/users?active=true

is interpreted with an https:// prefix because the input does not begin with a recognized scheme pattern. The reconstructed address is therefore based on https://localhost:3000/.... Likewise, example.com/docs becomes an HTTPS URL.

Treat that as an editing convenience, not proof that the real endpoint supports HTTPS. If protocol choice affects a test, enter it explicitly. The prefix behavior also means ambiguous text may be interpreted differently from a relative reference. /account/settings, for instance, is not resolved against your application’s current origin; this is an absolute URL parser, not a relative-link resolver.

Repeated Parameters and Encoding Details

Query strings may legally repeat a key:

https://api.example.com/items?tag=typescript&tag=react&limit=20

The parser preserves these as separate rows because it iterates every URLSearchParams entry. This is important for APIs that interpret repeated tag values as a list. Do not collapse them unless the target service documents comma-separated or array-style syntax.

Parsed row values are decoded by the URL API for editing, then encoded again when the URL is serialized. A source value such as hello%20world may come back as hello+world in the query. Both commonly represent a space in form-style query serialization, but a system that signs the exact raw query string may distinguish them. For signed requests, cache keys, or forensic comparison, retain the original text and avoid rebuilding it unless you intend to change its canonical representation.

Fragments follow different rules from query parameters. Everything after # belongs to the hash, even if it contains ? or &. If a server appears not to receive fragment data, that is expected HTTP behavior; move required request data into the path or query instead.

Debugging Invalid Input

“Invalid URL format” means the browser’s URL constructor could not interpret the trimmed input, even after the convenience HTTPS prefix was applied. Check these common causes:

• The port contains letters or falls outside accepted URL syntax, as in https://example.com:abc/.
• Brackets around an IPv6 literal are missing. Use https://[2001:db8::1]:8443/, not an unbracketed address.
• The hostname, percent escapes, or separators are malformed.
• Whitespace or prose has been pasted around or inside the address. Leading and trailing whitespace is trimmed, but embedded spaces still affect parsing.
• A relative path was supplied where an absolute host was intended.

When an error is shown, parsed fields are cleared to avoid presenting stale details from the previous URL. Correct the source input first; query-row editing only applies after parsing succeeds.

Where This Tool Fits in Development

During API debugging, isolate the origin and path before comparing query parameters against route documentation. During redirect review, inspect both the redirect target’s host and its fragment rather than scanning the string. For support tickets, remove account-specific values in editable rows before sharing a reproduction link. When building test fixtures, start from a known URL, add one parameter at a time, and copy the normalized result.

The parser is also useful for identifying embedded credentials. A non-empty Username or Password card means the authority contains user information such as user:pass@. Modern web systems should prefer authorization headers or managed credential flows because URLs can appear in logs, histories, screenshots, and monitoring data.

Scope and Limitations

This utility performs syntactic parsing in the browser. It does not request the URL, resolve DNS, follow redirects, test TLS, check whether a route exists, or determine whether a server will accept the parameters. A parseable address can still be unreachable or dangerous.

Only query parameters are editable through dedicated controls. The protocol, hostname, port, pathname, hash, username, and password cards are informational; edit those parts in the main URL field. The parser masks a displayed password but the original credential remains present in the input and rebuilt URL, so do not paste production secrets into material you plan to share.

Normalization follows the runtime’s WHATWG URL implementation rather than preserving every raw character choice from the source. This makes the tool appropriate for browser-oriented URLs, but not a substitute for comparing raw URI bytes or validating a vendor-specific URI grammar.

URL Parser FAQ

Why did the parser add https://?

Inputs without a leading scheme are treated as host-like addresses and receive an HTTPS prefix. Enter http://, https://, or another intended scheme explicitly when that distinction matters.

Why does a URL with no path come back with /?

The browser serializer represents the root path of an HTTP(S) URL as /. https://example.com and https://example.com/ identify the same root location in normal browser processing.

Are duplicate query keys preserved?

Yes. Each occurrence becomes a separate editable row and is appended again during reconstruction. Their order is retained while editing unless you remove or re-add rows.

Why is the password card masked?

Masking reduces casual exposure in the component breakdown. It is not secret removal: the main input and copied rebuilt URL can still contain the credential.

Can this parse a relative URL such as ../images/logo.svg?

Not relative to your site’s base URL. The tool attempts an absolute interpretation and may prepend HTTPS. Resolve the reference against a known base first if relative-path semantics are important.

Does a successful parse mean the URL is safe?

No. Parsing only establishes that the string fits the URL model. Review the destination, credentials, scheme, and parameters separately, and use network or security tooling when trust is in question.