URL Parser & Builder
Break any URL into its components or assemble a URL from parts — with a live query-param editor.
About this tool
Switch between Parse and Build modes. In Parse mode, paste any URL to see its protocol, credentials, hostname, port, pathname, query parameters (in an editable table), and fragment. In Build mode, fill in individual fields to assemble a valid URL. Add and remove query parameters, encode or decode the full URL, and copy the result with one click.
How to use
- 1 Choose Parse or Build mode using the tab buttons at the top.
- 2 In Parse mode: paste a full URL and see all components appear instantly.
- 3 Edit query parameter rows, then copy the updated URL.
- 4 In Build mode: fill in the protocol, host, path, and parameters to assemble a URL.
The anatomy of a URL
A URL looks like a single string, but it is really a structured record with up to eight distinct parts. Understanding those parts is the difference between guessing at why a link breaks and knowing exactly which segment is wrong. This tool parses any URL into its components and lets you edit each one, then rebuilds a valid URL from your changes. Take the example URL the input placeholder suggests:
https://user:pass@example.com:8080/path?a=1&b=2#section
| Component | Value here | Role |
|---|---|---|
| Protocol (scheme) | https: | How to talk to the server |
| Username | user | Optional credential |
| Password | pass | Optional credential |
| Hostname | example.com | Which server |
| Port | 8080 | Which service on that server |
| Pathname | /path | Which resource |
| Query | a=1&b=2 | Parameters as key/value pairs |
| Fragment | section | A location within the resource |
It follows the real URL standard
This is not a regular-expression guess. The tool uses the browser's native URL object, which implements the WHATWG URL Standard — the same parser your browser uses to load pages. That matters because URLs have surprisingly subtle rules: how default ports are handled, how the fragment is separated from the query, how Unicode hostnames are normalised. Because parsing goes through the genuine standard implementation, the components you see are exactly what a server or fetch call would receive. If the string cannot be parsed as a valid URL, the tool shows a descriptive error rather than silently producing garbage.
The live query-parameter editor
The most useful feature is the editable parameter table. After parsing, every key=value pair in the query string becomes its own editable row. Change a value, add a row, or delete one, and the full rebuilt URL updates instantly underneath. This is the right way to manipulate query strings, because the rebuilder re-encodes values correctly using the standard searchParams API — you never have to hand-escape an ampersand or a space. The table also shows a decoded view of each value beside the raw one, so you can immediately tell that %20 is a space and %2F is a slash.
A worked example
Paste a tracking-laden link such as https://shop.example.com/item?id=42&utm_source=email&utm_campaign=spring. The parser splits out the hostname shop.example.com, the path /item, and three parameters. Delete the two utm_ rows, leave id=42, and copy the result — you have a clean, trackingless link in two clicks. Or go the other way: in Build mode, choose https:, type the host, add a path, and add parameter rows, and the tool assembles a correctly-encoded URL from scratch. Build mode also exposes optional username, password, port, and fragment fields for assembling more complex URLs.
Encode versus decode
The Encode and Decode buttons in Parse mode apply encodeURI and decodeURI to the whole URL. Encoding converts characters that are not legal in a URL — spaces, accented letters, many symbols — into percent-encoded form (a space becomes %20). Decoding reverses that for readability. Note the distinction: encodeURI deliberately preserves the characters that give a URL its structure (:, /, ?, #, &), so it is safe to run on a whole URL without breaking it. That is different from encoding a single parameter value, where those structural characters must be escaped — which the parameter table handles for you automatically.
Use cases and pitfalls
- Cleaning marketing links by stripping
utm_and other tracking parameters before sharing. - Debugging API calls by confirming that each query parameter is spelled and encoded the way the server expects.
- Building deep links with the correct path and parameters without typing fragile escape sequences by hand.
- Inspecting credentials and ports embedded in connection strings.
- Pitfall — embedded credentials are not secret. The
user:pass@form is plainly visible in the URL and in server logs. Never treat it as secure; modern browsers also warn or strip it. - Pitfall — encode the value, not the whole string, when building manually. A raw
&inside a parameter value must become%26or it will be misread as a separator. The parameter table does this; manual string concatenation does not. - Pitfall — the fragment never reaches the server. Everything after
#is handled by the browser only, so do not put server-side parameters there.
All parsing, building, encoding, and decoding happen locally in your browser. URLs — which can contain tokens, IDs, and credentials — are never sent anywhere.