URL Decoder

Before decoding percent sequences, the decoder replaces every + with a space. That's right for query strings from HTML forms, where hello+world means "hello world".

It's wrong when the plus was meant literally and nobody encoded it, as in an unencoded Base64 value or phone number: a+b decodes to "a b". A properly encoded plus, %2B, comes through as +. If a decoded value has spaces where you expected plus signs, the sender didn't encode them, and you'll need to put them back by hand.

The decoder runs once. Text that was encoded twice keeps one layer of encoding:

• %2520 decodes to %20
• %252520 decodes to %2520

If your output still contains %XX sequences, paste it back into the input and decode again. Seeing %25 in a URL is the usual sign that something encoded it twice.

• A bare percent sign. 100% fails, because % must be followed by two hex digits. An encoded percent, 100%25, decodes to 100%.
• Bytes that aren't UTF-8. Some older systems encoded é as %E9 (Latin-1). That fails here, while the UTF-8 form %C3%A9 decodes to é.
• Broken sequences such as %zz, or a multi-byte character cut in half when a URL was truncated.

A single bad sequence fails the whole input, not only that part. If a long URL won't decode, split it and decode the pieces to find the problem.

Every sequence is decoded, including %26 (&) and %3D (=). name=Tom%20%26%20Jerry&x=1 becomes name=Tom & Jerry&x=1, and you can no longer tell which & separates parameters. To see each parameter's real value, use the URL Query String Parser, or split on & and = before decoding each value here.