URL Encoder / Decoder

Percent-encoding exists because a URL is a restricted alphabet wearing a longer one's clothes. RFC 3986 allows a URI to carry unreserved characters bare — letters, digits, and the four punctuation marks - . _ ~ — and defines everything else as either reserved, meaning it may carry structural meaning, or simply unsafe outside a URL context. The escape mechanism is uniform: take the character's UTF-8 bytes and write each one as a percent sign followed by two hexadecimal digits. A decoder runs the same rule backwards, which is what makes the scheme lossless for any text at all.

In practice two dialects of the scheme are in service, and they differ in exactly one place: how a space is written. RFC 3986 percent-encoding — what this page's Encode tab produces by default — writes it as %20. The older form dialect, application/x-www-form-urlencoded, was standardized around HTML form submission and writes the same space as +. Every other character encodes identically in both, which is why the mode selector changes so little and yet matters so much. The same input in each mode shows the shape of it:

Three of those rows are identical across the modes, and they repay a second look. The plus in a+b has to become %2B in both modes — in form mode because a bare plus would be read back as a space, destroying the value, and in RFC 3986 mode because the plus is reserved and this tool never leaves reserved characters bare. The punctuation row !'()* exists because JavaScript's encodeURIComponent quietly leaves those five unescaped, while RFC 3986's unreserved set does not include them; this page escapes them so its output survives the strictest parser. And the emoji row shows the byte arithmetic at work: four UTF-8 bytes, one escape each.

Decoding mirrors the same split. In form mode the decoder reads every plus as a space before resolving escapes, so a+b comes back as 'a b'; in RFC 3986 mode the plus is an ordinary reserved character and comes back a plus. That asymmetry is the single most common cause of a wrongly decoded URL parameter — a value whose pluses were literal, decoded with form mode, arrives with spaces where pluses used to be. When in doubt, decode a short sample both ways; the wrong mode announces itself immediately.

Every character an encoder meets falls into one of three tiers, and the tier decides the output. Unreserved characters — A-Z, a-z, 0-9, - . _ ~ — pass through untouched; encoding them would only make URLs longer for no benefit. Reserved characters — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — are legal in a URI but meaningful, so an encoder escapes them whenever they appear as data rather than structure. Everything else is unsafe in a URL by definition: spaces, quotation marks, angle brackets, accented letters, CJK characters, emoji, control characters. Percent-encoding exists to carry that third tier, and the character map panel on this page labels each character of your input with its tier as you type.

The percent row deserves its own line because it is the mechanism watching itself. A percent sign in your input can never be emitted bare: %25 is the only way a decoder can tell an intentional percent from the start of an escape. That is also why the character map gives % a class of its own — a % sitting in text you are about to encode is usually a sign that the text was already encoded once, and the map makes it visible before you create a %2520.

The character map lists one row per character, ordered as they appear in the input, with the character, its Unicode code point, its class and its encoded form. Emoji and other characters outside the Basic Multilingual Plane occupy a single row each, because the map counts code points rather than the surrogate pairs JavaScript uses internally to store them. Inputs longer than 500 characters stop the table there and note how many further characters were not listed — the encoding itself is unaffected, only the display is capped.

Double encoding is the most common self-inflicted wound in URL handling, and it follows from one fact: the percent sign is itself a character that must be encoded. Encode 'a b' and you get a%20b. Encode that result again, and the encoder does exactly what it is told — it sees a percent sign that needs protecting and writes %25 in its place, giving a%2520b. The string is now stable under further encoding, but it no longer decodes to what anyone expects: one pass of decoding yields a%20b, the literal characters percent-two-zero, and only a second pass recovers 'a b'.

It creeps in through layers that each look reasonable. A framework percent-encodes query parameters automatically, then a template escapes the URL again before printing it. A developer encodes a value 'to be safe' when it was already encoded upstream. A link is built by concatenating an encoded string into another URL that is itself encoded at the end. Each layer is individually correct; the composition is the bug. The symptom is always the same shape — encoded text appearing where a decoded value should be, a page showing %20, or a search endpoint that literally cannot find the words you typed.

The repair rule is to encode once and late: at the single point where a value leaves your code and enters a URL, using the component-level encoder, and never before. Any string that already contains %20, %2F or %3A should be treated as finished output, not as input to protect again. When you inherit a value that looks over-encoded, this page's Decode tab is the diagnostic: decode it, look at what comes out, and if the result still contains percent escapes, it was encoded twice — decode again and then go fix the producer rather than stacking another decode downstream.

Encoding can succeed on any input, but decoding can genuinely fail, and the failures divide into two families. The first is structural: a percent sign that is not followed by two hexadecimal digits. A string like 100% ends with a percent that has nothing after it, and %2 or %zz start escapes they cannot finish. Strict decoders refuse these rather than guessing, because treating a bare percent as literal text would make the outcome depend on the decoder's mood instead of the data. This page reports the problem in plain language instead of throwing.

The second family is byte-level: escapes that resolve to bytes which are not valid UTF-8. Percent sequences encode bytes, and bytes only spell characters when they follow UTF-8's rules — a lone %C3 promises a two-byte character and then never delivers the second byte, and %FF is not a legal UTF-8 start at all. Sequences like these usually mean the string was encoded from a different character set, Latin-1 being the usual suspect, and the honest answer is that the text cannot be recovered as written; it needs the character set it was actually encoded from.

One quiet trap sits between the families, and it is the plus again. Decode the form-encoded a+b with RFC 3986 mode and nothing fails — the tool returns a+b, technically correct and practically wrong, because the plus you are looking at was a space all along. Nothing flags it, because nothing is malformed. That is why mode choice is a question about the string's origin rather than its contents: malformed input announces itself, while a mode mismatch stays silent until a human notices the spaces that should have been pluses.