URL Encoder / Decoder & Query-String Parser

encodeURIComponent() escapes almost everything, so it is what you use on one piece of a URL — a single query value, a path segment. encodeURI() leaves the reserved characters : / ? # & = + and even # alone, so it is what you use on a URL that is already assembled and only needs its spaces and non-ASCII characters cleaned up. Pass a whole URL to encodeURIComponent and it becomes one opaque blob (https%3A%2F%2F…); pass a single value to encodeURI and any & inside it silently becomes a parameter separator. The Encode mode here exposes both: the default is the component rule, and the "Whole URL" checkbox is byte-for-byte encodeURI().

Both are correct, in different places. RFC 3986 only knows %20. The + convention comes from HTML form submission (application/x-www-form-urlencoded) and applies to form bodies and, by long habit, to query strings — which is why URLSearchParams decodes + as a space but leaves it alone inside a path. That means %20 is always safe, while + is only a space if whoever produced the value said so. The Decode mode shows you which convention it applied and lets you flip it, so you can tell "Ada+Lovelace" the name from "Ada Lovelace" the two words.

Percent-encoding replaces one byte with a % followed by that byte written as two hexadecimal digits. A URL may only carry a small set of ASCII characters, so anything else — a space, an accent, an emoji, or a reserved character being used as data — is first turned into UTF-8 bytes and then each byte is written as %XX. é is two bytes, so it becomes %C3%A9. Decoding reverses it: collect the bytes, then read them back as UTF-8.

Decode it twice. %2520 means the % of %20 was itself encoded to %25, which happens when a client calls encodeURIComponent() on a value that was already encoded — the classic OAuth redirect_uri bug. This tool detects it: paste the value into Decode mode and it reports that the first pass still contains escapes, shows you what a second pass produces, and offers a "Decode again" button. The real fix is upstream: encode exactly once, at the moment you place the value into the URL.

Because the escaped bytes are not valid UTF-8. %C3%A9 is a well-formed two-byte sequence and decodes to é, but %E9 on its own is the Latin-1 (ISO-8859-1) byte for é and is not legal UTF-8 — so it decodes to U+FFFD, the replacement character. This tool names the offending bytes instead of throwing a URIError the way decodeURIComponent() does, which tells you the value was encoded from the wrong source encoding rather than leaving you guessing.

Nothing in the URL standard says which one wins, so every row is listed here and the later ones are badged as duplicates. In practice PHP and Express keep the last value, Go’s r.URL.Query() returns all of them, ASP.NET joins them with commas, and Rails only groups them when the key ends in []. That disagreement is exactly why a tool should show you all the values rather than quietly picking one.

Punycode is the ASCII encoding of an internationalized domain name. DNS only carries ASCII labels, so münchen.example is converted to xn--mnchen-3ya.example before any lookup happens — and that ASCII form is also what a TLS certificate has to match. The parser here shows the converted host with the name you typed underneath it, so you can spot a lookalike domain. It deliberately does not convert punycode back to Unicode: rendering an attacker-supplied name as pretty Unicode is how homograph phishing works.

The unreserved set from RFC 3986 §2.3: A–Z, a–z, 0–9 and the four marks - . _ ~. Those are safe everywhere and must never be encoded gratuitously, because %2D and - are the same URL and re-encoding them breaks signature schemes that hash the raw string. Note that encodeURIComponent() also leaves ! ' ( ) * alone — a leftover from the older RFC 2396 "mark" set. RFC 3986 lists those five as sub-delimiters, so the component mode here escapes them and tells you when it disagreed with the browser built-in.

Not any more. HTML once suggested that servers accept ; alongside & as a parameter separator, and that advice was dropped from the spec in 2014. Browsers and URLSearchParams have never treated it as a separator, so a=1;b=2 is a single parameter named a whose value is the literal 1;b=2. This tool matches that behaviour and warns you when it sees a semicolon, because a legacy backend may still split on it and disagree with the browser sitting in front of it.

Yes — the entire tool is a static page with no server behind it. Parsing, encoding and decoding all run in your browser tab, nothing is uploaded, there is no logging and there is no account. That matters here more than for most tools, because query strings are exactly where access tokens, signed URLs, session ids and email addresses end up. If you want a second opinion, open your browser devtools network panel while you type: there is no request to make.