URL Encode / Decode
About URL Encode / Decode
This uses encodeURIComponent and decodeURIComponent, the same functions the browser applies when it sends a URL, so what you see here is what actually travels on the wire.
Which means spaces become %20 rather than +, Chinese becomes percent-encoded UTF-8, and &, =, ?, / get escaped too, because those characters carry meaning in a URL and would otherwise change what the link points to.
The + versus %20 thing
Form submissions (application/x-www-form-urlencoded) turn a space into +. encodeURIComponent does not. So a value copied out of a query string, decoded by a strict decoder, keeps its + — hello+world comes back as one word with a plus in the middle.
Rule of thumb: inside a path or a single parameter, use %20. In a whole query string, a + means space.
encodeURI and encodeURIComponent are not the same
They differ on :/?#[]@ — encodeURI leaves those alone so it can be applied to a complete URL, while encodeURIComponent escapes them so it can be applied to one value. Mixing them up is the usual bug in hand-built links: a parameter containing & silently splits into two parameters, and the server receives something you never sent.
This page does the component version, which is what you want for encoding a value.
Frequently asked questions
Why did my space turn into %20 instead of +?
Because this encodes a value, not a form. Both are valid in their own context: + only means space in form-encoded data, while %20 works everywhere.
Chinese text became a long run of %E4... — is that expected?
Yes. Each Chinese character is three UTF-8 bytes and each byte becomes one %XX triplet, so a single character turns into nine characters.
encodeURI or encodeURIComponent?
Component for a single value; encodeURI only when the string is already a complete URL and you just need the illegal characters escaped.
Why does decoding sometimes fail?
A stray % not followed by two hex digits, or a truncated multi-byte sequence. That string was never valid percent-encoding.
