Encode and decode URL parameter values
URL encoding (percent-encoding) rewrites characters that cannot appear literally in a URL: a space becomes %20, and non-ASCII text such as Chinese is first split into UTF-8 bytes and then encoded byte by byte, so 中 becomes %E4%B8%AD. Decoding reverses the process. It runs locally, so pasting full URLs with query strings is not a privacy concern.
Share links and callback parameters
Any time you build a share link, landing-page URL, or callback address containing Chinese text or reserved characters, unencoded &, =, or spaces will corrupt the URL structure. When reading analytics or server logs, decoding long runs of %E4%B8%AD is the only way to see what users actually searched for. And a surprising number of HTTP 400 errors come down to one parameter that was never encoded.
Percent encoding, spaces and reserved characters
encodeURIComponent and encodeURI are not interchangeable: the former encodes / : ? & = and is right for parameter values; the latter preserves those structural characters and is right for whole URLs. Using the wrong one either breaks the parameter or double-encodes it. Another classic trap is + in query strings: form-encoding treats it as a space, while a standards-compliant URL treats it as a literal plus — mismatched rules add or lose spaces.
Encoding uses encodeURIComponent. It leaves !, apostrophes, parentheses and * unescaped, so it is not a strict RFC 3986 canonicalizer for signing requests. Check the receiving API’s exact encoding requirements.
Should I encode a whole URL or one parameter value?
Encode each value separately. Encoding the entire URL also escapes : / ? and &, changing its structure. Form mode represents spaces as + and decodes + as a space; percent mode uses %20 and leaves a literal + unchanged when decoding.