URL Encoder & Decoder

The three dialects and the space

Inside a query value, encodeURIComponent-style encoding escapes &, =, / and everything else that could be misread, and a space becomes %20. On a whole URL, only what must be escaped is - the &, / and : that separate the URL are left alone or it stops working. In form data, a space becomes + and everything else follows the component rules.

Decoding reverses whichever dialect you say the text came from, which matters most for the +: a + decoded as component data stays a +, and a + decoded as form data becomes a space. The page’s default for form data turns the pluses back into spaces, because that is what form encoding did to them.

Encode once, the way double-encoding happens

Percent is itself a character the encoders know about, so encoding a URL that is already escaped will escape its % signs and turn %20 into %2520. That is not a bug in the page; it is the exact mechanism behind the %26 dance in query strings, and the page says so - encode once, and decode as many times as the string was encoded.

The classic culprit is a callback address: a framework percent-encodes its parameter once, the link builder does it again, and the server only unescapes one layer - leaving a literal %252F or %26 for the reader to trip over. Watching the input and output side by side shows how many layers piled up, which tells you how many times to decode rather than guessing.

Encoding is not encryption

Nothing here hides anything. Percent-encoding exists so URLs can carry characters, and the decoded form is one step away. The page makes that explicit because people paste encoded strings into it expecting privacy - and a %-escaped string is about as private as base64, which is to say not at all.

The person who receives the string needs no key: any decoder, this one included, reverses it in one step. So a token or password sitting inside an encoded URL is readable, and trusting this transformation with something secret is the same mistake as trusting base64 with it.

Non-ASCII text becomes UTF-8 bytes first

A non-ASCII character has no single percent sequence of its own: the page encodes its UTF-8 bytes, and each byte becomes one %XX escape. The accented e in "caf\u00e9" turns into caf%C3%A9, and a CJK character into three escapes. That is the same thing a browser does when it navigates to a URL containing those bytes - punycode, the other way domains are made URL-safe, is a separate scheme this page does not touch.

Because each character becomes the escapes of its own UTF-8 bytes, the same idea can look different under another encoding. This page works consistently in UTF-8, matching what a browser puts in the address bar, so a browser-escaped URL pasted in here decodes back to the same text rather than to mojibake.

What encoding does not fix downstream

A percent-encoded string is safe inside a URL and nowhere else. Drop it into an HTML attribute and the & that separates query parameters still has to be written as & in the markup; put it in a JSON body and the % signs are ordinary characters. Encoding answers "will the URL parser read this as structure", not "is this safe in every context".

Servers decode too, and some decode twice. A value that arrives with %20 already turned back into a space was decoded once before you saw it; one that arrives as %2520 was encoded again on the way out. Both are scope-and-layer problems, which is exactly what the scope setting on this page exists to make visible.

Practical URL ceilings are another limit the page cannot enforce. Browsers cope with very long URLs, but proxies, mail clients and server configs often cut around 2,000 characters. If an encoded payload approaches that, the link should carry an id and the data should live behind it.