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

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 %26 or 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.