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.

Choose Form mode. It applies application/x-www-form-urlencoded rules, turning + into a space while preserving a genuine plus only when it arrives as %2B. Component mode treats a bare plus as a literal plus, and Full URL mode preserves it with the rest of the URL structure. Selecting the correct mode avoids doing manual replacements that can corrupt phone numbers or tagged email addresses.

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.