URL Parser & Builder

Reading a URL piece by piece

A long URL is hard to read because several different things are packed into one line: where the request goes, what it asks for, and a trail of parameters added by whichever tools the link passed through. Paste one here and it is split into its parts using the same URL parser your browser uses, so what you see is what the browser would actually request.

https://shop.example:8443/items/42?q=caf%C3%A9+menu&utm_source=news#reviews

protocol   https:
hostname   shop.example
port       8443
path       /items/42   (items, 42)
query      q = "café menu"
           utm_source = "news"
hash       #reviews

The path is also shown as segments, which makes REST-style URLs easier to scan, and the port is marked when it is the default for the scheme. The hash is listed but never leaves the browser; it is not part of the request the server sees.

How query strings are encoded

The query is a list of key and value pairs joined with &. Because &, =, spaces, and non-ASCII characters have meaning or are not allowed in a URL, values are percent-encoded: a space becomes %20, an é becomes %C3%A9. Form submissions historically used + for a space instead, and both conventions are still common, so a value like caf%C3%A9+menu is shown decoded as café menu with a note that it used the plus form.

Keys can repeat. ?q=a&q=b is two rows, not one, because servers receive both and it is up to them how to combine them. A parameter with no = is a key with an empty value. A malformed percent sequence such as %2 cannot be decoded, so the raw text is shown with a warning instead of the whole URL being rejected.

Editing parameters and getting a correct URL back

The parameter table is editable. Change a value, add a row, delete one, or sort the list alphabetically, and the rebuilt URL at the top updates as you type. The rebuild goes through URLSearchParams and the URL API rather than joining strings, which is the part people get wrong by hand: an ampersand inside a value is encoded as %26, a Unicode character is encoded byte by byte, and a value that is itself a URL comes out safely escaped.

redirect = https://wapgee.com/tools?x=1&y=2
note = fish & chips

?redirect=https%3A%2F%2Fwapgee.com%2Ftools%3Fx%3D1%26y%3D2&note=fish+%26+chips

You can also paste just a query string, with or without the leading ?, when the URL does not matter and you only want to decode or tidy the parameters.

Stripping tracking parameters

Most links copied from email, social apps, or ad clicks carry parameters that identify the campaign or the visitor rather than the page: utm_source, utm_medium, utm_campaign and the rest of the UTM family, plus click ids such as fbclid, gclid, msclkid, ttclid, and mailing-list tokens like mc_eid and _hsenc. They make a link long, they leak which campaign you came from, and they cause the same page to appear under many URLs.

Strip tracking removes every parameter on that list in one click and tells you what it removed, so you can share the clean link. The list is deliberately conservative: only parameters that never change the page content are touched, and the removed rows remain in the table if one turns out to matter on a particular site.

https://example.com/post?id=7&utm_source=x&utm_medium=social&fbclid=IwAR0abc

https://example.com/post?id=7

Internationalised domains and lookalikes

Domain names can contain non-ASCII letters, and DNS stores them in an ASCII form called punycode that starts with xn--. The browser converts between the two, which is convenient and also the basis of lookalike phishing: a Cyrillic а in pаypal.com renders like the Latin one but is a different domain. When a pasted URL contains Unicode labels, the hostname is shown in both forms so the substitution is visible. Credentials embedded in the URL, the user:password@ form, are shown separately for the same reason: they are easy to miss in a long link.

Where it earns its keep

• Debugging an OAuth or payment redirect: paste the callback URL and read the state, code, and redirect_uri values without hand-decoding them.
• Cleaning a link before pasting it into a document, a commit message, or a support reply.
• Building a link with several parameters and being sure every value is encoded correctly.
• Checking a suspicious link from an email: the real hostname, embedded credentials, and any nested redirect target are laid out plainly.

Nothing you paste is stored, not even in the browser, because links often carry session tokens. If the parameter you are decoding is a JSON blob, the JSON, YAML and TypeScript converter will pretty-print it.