URL Encode/Decode

encodeURIComponent escapes more characters and is used for individual query/path values; encodeURI is used for a full URL and leaves structural characters intact.

No — encoding and decoding run entirely in your browser.

In path/query components spaces become %20; in form-encoded bodies they may become +. Both represent an encoded space.

Every percent sign in the input is itself escaped, so %20 becomes %2520 and %2F becomes %252F. The signature is that %25 running through the string; %252520 is three passes. It is the most common way a broken link arrives, usually because one layer was added by a framework or a form and a second by hand. Nothing here detects it — the function is applied to whatever you paste — so the fix is to decode repeatedly until the output stops changing, then encode once from the raw value. If a parameter reaches your server as a literal %20 rather than a space, you are looking at the same fault from the other end.

Replace the plus signs with %20 before decoding, or with spaces afterwards. The plus convention belongs to application/x-www-form-urlencoded — the format an HTML form posts, and the one many frameworks use for query strings — and it is not part of percent-encoding proper, so the browser's decoder hands back a literal plus and there is no setting here to change that. The trap runs the other way too: a genuine plus inside a value, in a phone number or a tagged email address, has to travel as %2B, because a form-encoded parser reads a bare one as a space. Component mode escapes it for you; Full URI mode leaves it alone.

Because the browser's encoder and most signing specifications disagree about five characters. encodeURIComponent leaves ! ' ( ) and * unescaped alongside the unreserved set of letters, digits and - _ . ~ — but canonical signing schemes, AWS Signature Version 4 among them, escape everything outside that unreserved set, demand uppercase hexadecimal digits and insist a space is %20 rather than a plus. The hex case agrees, since the function emits uppercase; those five characters do not. A string that is a valid URL therefore still hashes differently from the one the server rebuilt. If your values can contain them, escape them yourself afterwards — %21 %27 %28 %29 %2A — or let your SDK's own encoder do it.

No, and treating it as protection is how secrets end up somewhere nobody intended. Percent-encoding is a published table, reversible by anyone in one paste, and browsers, proxies and log viewers routinely show the decoded form anyway. Whatever sits in a URL is written into server access logs, browser history, the Referer header sent to third-party scripts and usually an analytics pipeline — escaped or not. That is the argument for keeping session tokens, password reset codes and API keys in a header or a request body instead of a query string. Encoding also does nothing for the layers next door: an escaped string still needs HTML escaping before it reaches a page, and parameterisation before it goes near a database.

The decoders assume UTF-8, which is what the standard expects and what almost everything emits now. Text escaped on an older system in Latin-1 writes é as %E9 rather than %C3%A9, and %E9 is not valid UTF-8, so decoding fails outright with a malformed sequence instead of showing you the wrong letter. Something that does decode but reads as é is the opposite case: UTF-8 bytes already misread as Latin-1 somewhere upstream, and re-encoding the result will not undo it. Expect the cost on the way in as well — each byte of a non-ASCII character becomes three characters, so an emoji goes in as twelve, and long query strings meet request-line limits sooner than they look like they should.

Because several servers refuse to decode an encoded slash inside a path segment before routing, on the grounds that it could be used to climb out of a directory. Apache rejects it unless AllowEncodedSlashes is switched on, Tomcat blocks it by default, and a proxy in front of either may normalise it into a real slash, which changes the route entirely. The practical conclusion is that a value containing a slash is safer as a query parameter than as a path segment, however correctly it was escaped. Case is not the issue: %2f and %2F are equivalent and decoders treat them as such, though the standard prefers uppercase and the encoder here emits it.