URL Encoder & Decoder

A URL may only contain a small set of ASCII characters, and a handful of those are reserved for punctuation: the slash that separates path segments, the question mark that starts the query, the ampersand between parameters. Anything else — a space, an accent, an emoji, or a reserved character being used as data rather than punctuation — has to be percent-encoded, which means writing each of its UTF-8 bytes as a % followed by two hex digits.

This page does that in both directions, and does the thing most people actually arrive wanting: paste a long URL and read its query string as a table, with every parameter decoded on its own. That is the view that answers why a redirect is landing in the wrong place or why a tracking link has swallowed half of another URL.

Everything runs in the page. The URLs people bring to a decoder are session links, password resets and OAuth callbacks, and those have no business being posted to somebody else's server to be read.

Encoding a whole URL leaves the structural characters — : / ? # [ ] @ & = + $ , ; — untouched, because in a complete address they are doing their job. A space becomes %20 and an accented letter becomes its UTF-8 bytes, but the address still parses as an address.

Encoding a component escapes those characters too. Inside a single query value an ampersand is not a separator, it is part of the data, and leaving it alone splits your one parameter into two. This is the mode you want when you are building a URL by concatenation: encode each value as a component, then join them with the punctuation.

Getting it backwards is the classic cause of a URL that works until someone's name contains an ampersand, or a redirect that drops everything after the first & in its target. If you are ever unsure, ask whether the text you are encoding is a whole address or one piece of data. Pieces of data are components.

Percent-encoding is not idempotent. Encode a space once and you get %20; encode that result again and the percent sign itself is escaped, giving %2520. It is a real, valid string — it just decodes to %20 rather than to a space.

This happens when a value is encoded by a library and then again by a framework, or when a URL is passed as a parameter to another URL and each layer escapes it in turn. The symptom is a link that resolves to something visibly containing %20 or %3A, or a redirect that fails because its target is not the URL you meant.

The parameter table flags any value that still contains percent-escapes after one decode, which is the fingerprint of double encoding. Decode it once more to see what was originally intended, then fix the layer that is escaping twice — decoding at the far end is a workaround that breaks the first time a value legitimately contains a percent sign.

%20 is a space everywhere in a URL. The plus sign means a space only in application/x-www-form-urlencoded data — the format a submitted HTML form produces — which in practice is the query string and nothing else. In a path segment a plus is a literal plus, which is why file names with a plus in them survive but search terms sometimes do not.

This encoder always produces %20, because it is correct in both contexts. When decoding, the plus-as-space option lets you say which convention the text you have was written under; the parameter table always applies the form rule, since that is what a query string is.

The case that catches people is a base64 value in a query string. Base64 uses + as one of its characters, and if it is not escaped as %2B a form-decoder will turn it into a space and corrupt the data. Encoding it as a component first is what prevents that.

It makes text safe to put in a URL. It does not make text safe to put in HTML, in SQL, in a shell command or in a JSON string, and reaching for it in those places is how injection bugs happen. Each of those contexts has its own escaping rules and its own library function.

Nor is it any kind of secrecy. Percent-encoding is fully reversible by anyone, exactly like Base64, and a URL travels through browser history, server logs, proxies and the Referer header of every page it leads to. A secret in a query string is a secret written down in several places you do not control, encoded or not.

It is also worth knowing that the fragment — everything after the # — never reaches the server at all. The browser keeps it. That is why single-page apps use it for routing, and why OAuth's implicit flow, which returned access tokens there, is now discouraged: the token ends up in browser history.