URL encoder and decoder

The two differ on exactly one thing: what they do with the reserved characters, the punctuation that gives a URL its shape. Those are ; / ? : @ & = + $ , and #.

encodeURI leaves them alone, because it assumes you handed it a complete address where a slash separates path segments and an ampersand separates parameters. It escapes spaces and non ASCII characters and nothing else.

encodeURIComponent escapes them, because it assumes you handed it one piece of data that has to survive being dropped inside a URL. A slash in a search term is part of the term, not a path separator, so it has to become %2F.

The rule that follows: encodeURIComponent for the values, encodeURI for the whole thing. Getting it backwards is the classic bug. A search for red & blue encoded with encodeURI keeps its ampersand, so the server sees a parameter q=red and a second parameter called blue, and the search silently runs on half the query.

Everything outside that list behaves identically in both. Letters, digits and the characters - _ . ! ~ * ' ( ) pass through untouched, and anything non ASCII becomes its UTF-8 bytes written as percent escapes, which is why an accented e is two escapes and an emoji is four.

Percent encoding says a space is %20. The application/x-www-form-urlencoded format, which is what an HTML form submits and what most query strings use in practice, says a space is a plus sign. Both are correct in their own context, which is precisely why they cause trouble.

A plus sign inside a path segment is a literal plus. A plus sign inside a form encoded query value is a space. Decode with the wrong rule and you get spaces where a plus was meant, which quietly corrupts phone numbers, chemical formulae and anything else where the character matters. That is why form encoding is listed here as its own result rather than folded into the other two.

What is the difference between encodeURI and encodeURIComponent?

encodeURIComponent escapes the reserved characters, so a slash becomes %2F and an ampersand becomes %26. encodeURI leaves those alone, because in a whole URL they are structure rather than data. Use encodeURIComponent for one query parameter value or path segment, and encodeURI for a complete address that only needs its spaces and non ASCII characters fixed.

Which one should I use for a query string value?

encodeURIComponent, every time. If the value contains an ampersand or an equals sign and you used encodeURI, those characters survive unescaped and the server reads them as the start of the next parameter, which truncates your value or invents one that was never sent.

Why does a space sometimes become %20 and sometimes a plus sign?

Both are correct, in different places. Percent encoding says %20. The application/x-www-form-urlencoded format, which HTML forms submit and most query strings use, says a plus sign. A plus in a path segment stays a literal plus, which is why decoding with the wrong rule turns plus signs into spaces that were never there.

Is the encoding done on your server?

No. It runs in your browser, so the URL, the token or the search query you paste stays on your device and is never uploaded or logged.

Why did my decode fail with a malformed escape error?

A percent sign has to be followed by exactly two hexadecimal digits, so a literal percent in text has to be written %25. A stray percent, as in a copied 100% figure, breaks decoding. The other cause is a multi byte character that was copied in half, which leaves valid looking escapes that do not spell out valid UTF-8.

Does percent encoding hide anything?

No. It is a formatting rule, not a security measure. Anyone can decode it in one step, so a token or an email address in a URL is exactly as readable after encoding as before.