URL Encoding Reference

Common escapes

space

%20

!

%21

#

%23

$

%24

&

%26

'

%27

+

%2B

,

%2C

/

%2F

:

%3A

;

%3B

=

%3D

?

%3F

@

%40

%

%25

é (UTF-8)

%C3%A9 — two bytes, two escapes

The distinction that causes the bugs

encodeURI

a WHOLE URL — leaves : / ? # [ ] @ & = + $ , alone

encodeURIComponent

one VALUE going into a URL — escapes ALL of those

This tool does

COMPONENT — the one you almost always want

⚠ The classic failure

'salt & pepper' arrives as two parameters

⚠ Whole URLs

encode the PIECES, then assemble

⚠ + is NOT a space

that is form encoding, a different thing

⚠ Double-encoded

%20 has become %2520

⚠ Empty decode

the input is not valid percent-encoding

Encoding works on

BYTES — UTF-8, so non-ASCII takes several

Debugging a broken URL

• Decode it and read what actually arrived
• Look for %25 — that means it was encoded twice
• Check whether a value contains & or = unescaped
• Check whether + was meant to be a space (form encoding)
• Confirm each VALUE was encoded, not the assembled address
• Re-encode the decoded version and compare with the original
• Check non-ASCII characters survived as multi-byte escapes

Encode the pieces, not the address

A value going INTO a URL must not be able to punctuate it. Encode a search term containing an ampersand with a whole-URL encoder and the ampersand survives — so the server reads the rest of your term as a separate parameter. Build URLs from separately encoded parts; never run a finished address through a component encoder either, or you will escape the slashes that make it work.

%25 means it was encoded twice

Percent signs are themselves escaped as %25, so running an already-encoded string through an encoder again turns every escape into a longer one. Once you can recognise %2520 as a double-encoded space, this whole class of bug becomes obvious on sight instead of mysterious.