URL Encoder / Decoder

A URL encoder exists because URLs are text with a grammar. Characters that carry structural meaning — ? starts the query, & separates parameters, # starts the fragment, / separates path segments, % starts an escape — cannot appear literally inside a value without changing how the URL is parsed. Percent encoding is the escape hatch: every unsafe character becomes % followed by two hexadecimal digits, and a URL decoder reverses exactly that.

This URL encoder and decoder pair covers both directions plus the inspection step most tools skip: percent-encode a component or a whole URL, decode %XX escapes back to text, and parse any pasted URL into protocol, host, path, query parameters and fragment. Everything runs locally in the browser, which is what you want when the link you are dissecting carries tracking data.

The reserved character problem in URL encoding

Consider a search for rock & roll. Naively assembled, ?q=rock & roll produces a query string with a parameter named q holding rock and a second malformed parameter. The ampersand has to become %26: ?q=rock%20%26%20roll.

This is what encoding is for, and it is why every URL-building helper in every framework does it for you. The bugs appear when you encode manually on top of an automatic encoder, or forget entirely.

Two functions, two jobs in URL encoding

encodeURI produces a valid URL from a string that is already shaped like one. It escapes the genuinely unsafe characters — spaces, quotes, non-ASCII — and leaves the structural ones intact.

encodeURIComponent produces a valid URL component. It escapes structural characters too, because inside a query value an ampersand is data, not structure.

The mistake is symmetric and common: using encodeURI on a parameter value lets & and = through and corrupts the query string; using encodeURIComponent on a whole URL escapes the :// and the path separators, producing something unrecognisable.

URL decoding and the plus sign

In application/x-www-form-urlencoded — the format browsers use for form submissions — a space is encoded as +. In RFC 3986 percent-encoding, + is a literal plus and a space is %20. Both conventions appear in the wild, and a decoder has to know which it is dealing with.

The practical consequence: decoding a+b with form semantics gives a b; with strict percent semantics it gives a+b. This tool lets you choose, and defaults to form semantics for query strings because that is what almost all real traffic uses.

The URL parser built into the decoder

Beyond encoding and decoding, the most useful thing this tool does is decompose. Paste a long marketing URL and you get the protocol, host, port, path, every query parameter decoded into readable values, and the fragment. That is the fastest way to understand what a tracking link is actually doing, and to spot a double-encoded value or a parameter that has been silently dropped.

When to percent-encode a URL by hand

Modern frameworks encode for you, so the remaining manual cases are narrow but real: assembling a URL in a spreadsheet or a script, cleaning up a link someone else hand-built, debugging a value that arrived double-encoded, or preparing a redirect target for a config file. In each case the rule is the same — encode parameter values with component rules, never the assembled URL, and encode only once. If a value already contains %26 and you encode it again, the receiver decodes once and is left holding a literal & inside the parameter where structure was intended.

Decode URL parameters for debugging

The decoder doubles as a query string debugger. Paste the URL of a tracking link, an email campaign, or an integration webhook, and every utm_ and vendor parameter is broken out as a name-value pair with its percent escapes resolved. That is the fastest way to spot the parameter that arrived empty, the value that was encoded twice, and the one name the receiving system silently dropped. For marketers and developers alike, decoding URL parameters before trusting a link is a thirty-second check that prevents hour-long disputes.

A free URL encoder decoder that stays local

No URL you paste is transmitted. That matters less for a public link and considerably more for internal endpoints, signed URLs with auth parameters, and customer-specific tracking links — the kind of URLs that should not end up in a third-party service's logs. Encode, decode, parse, copy: the whole URL encoder decoder loop is client-side and free.

The unreserved set and when encoding is optional

A–Z, a–z, 0–9, hyphen, underscore, period and tilde never need encoding anywhere in a URL. Everything else is technically required to be encoded inside a component, though forgiving parsers tolerate plenty in practice. Relying on that tolerance is how a link works on your machine and breaks for a customer whose client is stricter — percent-encoding the value properly is the same amount of work and behaves identically everywhere.