URL Encoder & Decoder

encodeURI versus encodeURIComponent

encodeURIComponent escapes everything that is not unreserved, including / ? : @ & = + $ #. Use it for a single piece of data going into a URL — one query value, one path segment. encodeURI deliberately leaves those characters alone because it assumes you are handing it a complete URL whose structure must survive.

Using the wrong one produces two distinct bugs. Encode a whole URL with encodeURIComponent and the slashes and colon become %2F and %3A, so it is no longer a URL. Encode a query value with encodeURI and an ampersand inside it stays raw, so the server splits your one parameter into two — a classic parameter-injection vector.

Plus signs are the other classic trap

In a query string, historic application/x-www-form-urlencoded rules let + mean a space. Percent-encoding rules do not. So a+b in a query string may arrive as “a b” or as “a+b” depending on what parses it. If a literal plus matters — phone numbers in E.164 format, for instance — encode it as %2B and stop relying on the reader to guess.

Non-ASCII goes through UTF-8 first

Percent-encoding escapes bytes, not characters. A character outside ASCII is first encoded to UTF-8 and each byte then becomes %XX. So “à” becomes %C3%A0 — two escapes for one character. This is why the encoded length grows so much faster than the character count for non-English text, and why a URL truncated mid-escape cannot be decoded at all.

Double encoding

Encoding an already-encoded string turns every % into %25, so %20 becomes %2520. It is reversible if you decode exactly as many times as you encoded, and a source of very confusing bugs if you lose count. If a value arrives with %25 in it, suspect an extra encoding pass somewhere upstream.

Frequently Asked Questions