Percent Encoding URL: The Rules Behind %XX

Three sets of characters

Unreserved — A-Z a-z 0-9 - _ . ~ — are always safe and must never be encoded. Encoding them is legal but produces a non-canonical URL that breaks cache keys and signature comparisons.

Reserved — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — carry structural meaning. Encode them when they appear as data, leave them when they are doing their structural job.

Everything else — space, quotes, backslash, braces, control characters and all non-ASCII — must always be encoded.

Non-ASCII becomes UTF-8 bytes

A character outside ASCII is first encoded to UTF-8, then each byte becomes %XX. é is two bytes and gives %C3%A9; € is three and gives %E2%82%AC; an emoji is four.

That is why a Cyrillic or Chinese query string looks enormous when encoded. It is correct — one character legitimately expanding to twelve characters of escape.

Legacy systems sometimes emit single-byte escapes such as %E9 for é in Latin-1. Those are not valid UTF-8 and strict decoders reject them.

Context decides

The same character needs different treatment in different parts of a URL. In a path segment, / is a separator and a literal slash in data must be %2F — though many servers reject or normalise %2F in paths, so avoid slashes in path data entirely.

In a query string, encode each key and each value separately, then join with & and =. In a form body, a space is + rather than %20, and a literal + must therefore be %2B.

In a fragment, encoding is looser because the fragment never reaches the server — but encode anyway for consistency.

Canonical form

Two URLs that differ only in encoding are logically the same but textually different, and anything comparing strings — caches, CDNs, signatures, analytics — treats them as distinct.

Keep to one form: encode exactly the characters that need it, use uppercase hex digits (%2F, not %2f), and never double-encode. %25 appearing in your URLs is the signal that an encoder ran twice.