URL Encoding Explained: Percent-Encoding, %20 and Common Bugs

What URL encoding actually is

URL encoding, also called percent-encoding, is how a URL carries characters it is not allowed to contain. A URL may only use a small set of ASCII letters, digits and punctuation. Everything else — a space, an accented letter, an emoji, a Cyrillic or Arabic word — has to be written as a % followed by two hexadecimal digits for each byte.

The same trick is used for characters that are allowed but mean something. A ? starts the query string and an & separates parameters, so a search for fish & chips has to send the ampersand as %26, or the server sees two parameters instead of one.

That is the whole job: make a value safe to put inside a URL without changing what the URL means. It is not compression, not encryption and not a security filter.

How a character becomes %XX

Encoding works on bytes, not characters. The text is first turned into UTF-8 bytes, then every byte that needs encoding is written as % and its value in hex.

A plain ASCII character is one byte, so a space (byte 32, hex 20) becomes %20. Characters outside ASCII take two to four bytes in UTF-8, and each byte gets its own escape:

• é → bytes C3 A9 → %C3%A9
• € → bytes E2 82 AC → %E2%82%AC
• 😀 → bytes F0 9F 98 80 → %F0%9F%98%80

Decoding reverses the steps: collect the bytes, then read them as UTF-8. If the bytes were produced with a different character set, such as Latin-1, the result comes out as mojibake — café instead of café. Every modern browser and framework uses UTF-8, and you should too.

Reserved, unreserved and why context matters

RFC 3986 splits URL characters into two groups.

Unreserved characters — A–Z a–z 0–9 - . _ ~ — never need encoding. Encoding them is legal but pointless, and a good encoder leaves them alone.

Reserved characters — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — give a URL its structure. Whether you encode one depends on where it is. The / between path segments must stay a slash; a / inside a file name you are passing as a parameter must become %2F. That is why there is no single right way to "encode a URL": you encode each piece for the place it is going.

encodeURIComponent vs encodeURI

JavaScript has two built-in functions and picking the wrong one is the most common URL bug there is.

Run encodeURI on a value like a&b=c and the & and = survive, so your one parameter becomes two. Run encodeURIComponent on a whole URL and every / and : is escaped, so the link stops being a link. The rule of thumb: build URLs from pieces and encode each value with encodeURIComponent — or better, let URLSearchParams do it for you.

Other languages have the same split: Python's quote and quote_plus, PHP's rawurlencode and urlencode. Our URL encoder and decoder offers both modes so you can see the difference on your own input.

+ or %20: the form-encoding exception

In a path, a space is %20 and a + is just a plus sign. But HTML forms submitted with the default application/x-www-form-urlencoded type encode a space as + in the query string, and servers decode it back.

The trouble starts when the two conventions meet. A phone number like +44 20 7946 0000 put into a query string without encoding arrives as 44 20 7946 0000, because the server read the + as a space. The fix is to encode the plus as %2B, which every encoder that follows the form rules does. When you are unsure which convention the other side expects, %20 for a space and %2B for a plus are always safe.

Double encoding and the %2520 bug

%25 is the encoded form of the percent sign itself. So when you see %2520 in a URL, it is %20 that was encoded a second time: a value went through an encoder after it had already been encoded.

It usually happens at a boundary — a framework encodes a parameter that the calling code had already encoded, or a redirect URL is encoded once to fit inside another URL and then again by a library. The visible symptom is a 404, a search for the literal text %20, or a filename full of percent signs.

Decoding twice recovers the original, but the real fix is to find the second encoder and remove it. Encode exactly once, at the moment a value is placed into a URL.

Encoding is not escaping, and not encryption

Percent-encoding makes a value safe inside a URL. It does nothing for HTML, JavaScript or SQL. Once the server decodes %3Cscript%3E it has a perfectly ordinary <script> again, so output still has to be escaped for wherever it ends up, and database queries still need parameters.

It is not secrecy either. Anyone can decode a URL, and URLs are written to server logs, browser history, analytics tools and the Referer header of the next page. Never put a password, token or personal data in a query string because it "looks scrambled". The same is true of Base64, as our Base64 guide explains.

When decoding goes wrong

Most URL problems are one of these:

• "URIError: malformed URI sequence". A % is not followed by two hex digits, or the bytes are not valid UTF-8. A literal percent sign must itself be sent as %25.
• Accents come out as é or �. The bytes were written in one character set and read in another. Make sure both sides use UTF-8.
• A parameter is cut short at an &. The value was not encoded, or was encoded with encodeURI instead of encodeURIComponent.
• Plus signs turn into spaces. Form decoding treated + as a space. Encode a real plus as %2B.
• %2520, %253D and friends. Double encoding; find the second encoder.

Paste the URL into a decoder and look at each query parameter separately — the breakdown usually makes the problem obvious within seconds.

Related tools and guides:

• URL Encoder & Decoder - Percent-encode text or a whole URL, decode %XX back to text and see every query parameter.
• Base64 Encoder & Decoder - Encode text to Base64 or decode it back, with URL-safe output and UTF-8 handled.
• Base64 Explained: How Encoding and Decoding Really Work

Frequently Asked Questions