URL Encoder / Decoder
encodeURIComponent or the looser query-string rules, both ways, with the difference explained.
—
Worked example
A space becomes %20 in a path but + in an application/x-www-form-urlencoded body. Both decode to the same character; mixing them up produces literal plus signs in submitted forms.
Percent-encoding replaces characters that are not allowed in a URL with a percent sign and two hex digits of their UTF-8 bytes. Everything else passes through. Which characters are "not allowed" depends on where in the URL the string lands, and that is where most encoding bugs come from.
Two scopes, two rules
encodeURIComponent escapes everything except letters, digits and - _ . ! ~ * ' ( ). Use it for a value being placed into a single parameter — a search term, a filename, a redirect target. encodeURI leaves the structural characters & = ? / # : alone and is for encoding a whole URL you already assembled.
Encoding a complete URL with encodeURIComponent is a classic mistake: the slashes and query separators get escaped, and the server receives one long path segment.
Double encoding
If a parameter arrives with %25 where you expect %, it was encoded twice — usually once by the form and once by the code that built the link. Decoding once reveals the second layer; decoding blindly in a loop is how injection payloads slip past filters, so decode exactly as many times as you encoded.
Not a security control
Percent-encoding is a transport rule, not a sanitiser. Encoding user input does not make it safe to concatenate into SQL, HTML or a shell command. Those need their own escaping at their own boundary.