URL Parser
Preparing tool controls…
A URL parser separates a web address into its protocol, hostname, port, pathname, query parameters, and fragment. This tool uses the URL standard to interpret an HTTP or HTTPS address, displays repeated query keys in their original sequence, and allows you to rebuild the address after editing parameter rows. A relative reference can also be resolved against an explicit base URL when that option is enabled.
Url Parser Online At a Glance
| Property | What to expect |
|---|---|
| Accepted schemes | HTTP and HTTPS |
| Query processing | Ordered rows with duplicate keys retained |
| Editing | Query names, values, path, and fragment |
| Encoding behavior | Standard URL and URLSearchParams serialization |
| Safety | Credentials blocked in the query editor |
Understanding a Web Address as Separate Components
Consider the example https://example.com:8443/shop/items?color=blue&color=red#reviews. The scheme specifies HTTPS, the host identifies example.com with an explicit port, the pathname identifies a location on that host, the query contains two occurrences of color, and the fragment names a local document position. These components play different roles. The fragment is generally handled by the browser and is not sent as part of an ordinary HTTP request, whereas the query string usually travels to the server. Parsing the address makes those distinctions visible without requiring you to count punctuation manually.
Hostnames may contain internationalized domain names represented through Punycode, and an address can contain percent-encoded bytes in its path or query. A URL parser must preserve those distinctions instead of splitting a string at the first question mark and treating every ampersand as interchangeable. This tool uses the web platform URL implementation to interpret structure, normalizes what the standard requires, and lists decoded query names and values. For a raw string that only needs percent encoding or decoding, URL encoding and decoding addresses component-level transformations rather than decomposition of a full address.
What the Protocol, Authority, Path, Query, and Fragment Mean
The protocol is the scheme that determines how a client interprets the address; ordinary webpage inspections support HTTP and HTTPS. The authority includes the hostname and, where explicitly present, the port. A standard HTTPS address usually omits :443 because that is the default port. The path is hierarchical text after the authority and may include percent-encoded characters to keep reserved delimiters inside a segment. Treat the browser's normalized pathname as an encoded path, not as a filesystem path you can safely open on a local machine.
Query parameters often represent filters, pagination, language selections, campaign tags, or serialized application state. Repeated keys are legal and sometimes intentional: a shopping filter can carry category=books&category=games. Some frameworks combine repeated values into arrays, others keep only one, so editing tools should not silently collapse them. The fragment identifies a section or client-side state without changing the core resource requested by the HTTP transaction. In applications using hash-based routing, changing the fragment can affect what users see even though the network URL sent to the server stays the same.
Editing Query Values Without Losing Repeated Parameters
After parsing, the editor presents one row per parameter in source order. Change a row's name or value, add another row, or remove a row, then rebuild the address. The tool recreates the query with URLSearchParams, which serializes spaces and reserved characters according to form-style query rules. A space may become a plus sign rather than %20 in the rebuilt query. This is normal for URLSearchParams; the two spellings are often decoded to the same space by form parsers, although applications that compare raw URLs or signatures may distinguish them. Always review the final serialized address for systems that depend on exact raw bytes.
For a concrete example, start with https://example.com/search?q=blue+shoes&tag=sale&tag=new. Three query rows appear because tag is repeated. Replace q with “blue & white shoes” and preserve both tag rows. The rebuilt query percent-encodes the ampersand within the q value instead of treating it as a new parameter delimiter, and the two tag entries remain separate. If you need to remove unnecessary marketing parameters before sharing a link, the campaign link cleaner handles tracking-oriented cleanup, while this parser deliberately leaves all entries available for exact inspection and manual editing.
Relative URL Resolution and Validation
Relative references such as ../products?id=7 only acquire a complete meaning in relation to a base address. If the base URL ends at https://example.com/shop/category/, the parent reference navigates relative to that path before applying the new query. Enable relative parsing only when you know which document acts as the base. An accidental base can produce a valid-looking address pointing to the wrong section or host. The editor requires an explicit scheme for normal absolute inspection so arbitrary text does not silently become a search term or local file reference.
Malformed percent sequences are rejected before parsing because they often hide a transcription error. URLs containing user information are rejected during parsing and rebuilding so credentials cannot be accidentally exported as part of a report. An address using HTTP triggers a review warning; it is not automatically rewritten to HTTPS because a destination may not support a secure endpoint. A Punycode host receives a reminder to check the intended name, particularly when copy-and-paste introduces visually similar international characters. None of these observations proves that the destination is trustworthy, accessible, or correctly configured.
Canonicalization, Query Semantics, and Limits
Normalization can be surprising. A URL object may lowercase a hostname, remove a default port, encode certain characters, or resolve dot segments. Rebuilding through URLSearchParams can change the visual form of separators and spaces even when decoded parameters remain equivalent. A signed API URL may break if a server validates the raw query string byte for byte and the editor reserializes it. For payment links, signed cloud storage URLs, OAuth redirect values, and temporary access tokens, treat parsed output as diagnostic and avoid reconstructing without understanding the signature requirements.
The tool does not perform a network request, follow redirects, or certify the final status of an address. If a link should be tested against a server, an HTTP status checker can inspect the actual response, subject to remote access and robots restrictions. The parser is most useful when you need to understand why a parameter is duplicated, whether an encoded character belongs to the path or query, or how a fragment changes a copied link. Keep sensitive access tokens out of exported reports and remember that query parameters may be logged by analytics software, proxies, and web servers.
Recognizing Encoded Delimiters and Parsing Surprises
An encoded question mark inside a path segment is not the beginning of a query. For instance, /help%3Ftopic=one is a path containing an encoded punctuation character, while /help?topic=one has a query parameter. The same distinction applies to %23 versus a literal fragment delimiter and to %26 inside a query value versus an actual ampersand separating parameters. Looking at both the encoded pathname and the decoded parameter rows prevents an editor from accidentally changing where a piece of data belongs. When reconstructing a path by hand, retain slash boundaries and do not decode reserved punctuation indiscriminately.
International characters add another layer. A hostname may be written in Unicode but standardized to Punycode for storage and transport. Query and path values can contain UTF-8 percent-encoded sequences, yet not every backend agrees about normalization, case sensitivity or repeated fields. A successful parse means the browser can represent the URL, not that a particular server route exists. If the parsed address controls destructive actions, authenticated sessions, or signed resources, compare the original raw value against the proposed rebuilt value instead of trusting visual similarity.
Frequently Asked Questions
Does parsing a URL open the website?
No. Parsing only interprets the provided characters using browser URL rules. The address may be perfectly valid even if the server is offline, the domain does not resolve, or the endpoint returns an error.
Will repeated query parameters survive editing?
Yes. Each original occurrence becomes a separate row, and rebuilding appends each row in order. If you delete a duplicate deliberately, only the remaining rows appear in the result. How a destination server interprets duplicates varies.
Why did spaces become plus signs?
URLSearchParams serializes query values using form-style rules, where spaces are represented by plus signs. A literal plus sign in the value is encoded separately. Applications using raw signature strings may require the original encoding instead.
What is the difference between a query and a fragment?
A query begins after the question mark and typically participates in the HTTP request. A fragment starts after the hash sign and is generally interpreted on the client side for anchors or interface state.
Can the parser inspect a relative link?
Yes, when you explicitly enable relative URL parsing and provide a valid base URL. The resolved address depends on that base. Without one, the same relative path can point to many different absolute locations.
Should URLs containing passwords or tokens be shared?
Avoid sharing them. Usernames and passwords embedded in URLs are particularly risky and are blocked from the rebuild operation. Query tokens can also contain secrets, so review every parameter before copying an address or exporting a report.
Conclusion
A parsed address is easier to reason about when every component and query occurrence is visible. Use the query editor to make intentional changes, preserve meaningful duplicate keys, and recheck serialization whenever signatures or application-specific routing are involved. Parsing clarifies a URL; it does not establish the safety or availability of its destination.