URL Encoder

A URL can only contain a restricted set of ASCII characters. Everything else — spaces, accents, ampersands inside a value, slashes that are data rather than path separators — has to be percent-encoded, written as % followed by two hex digits of the UTF-8 byte. Skip that step and your link breaks in ways that are annoyingly inconsistent: it works in one browser, gets truncated by another, and silently loses half a parameter when a proxy rewrites it.

The decision that actually matters on this page is which of the two encodings you want, and getting it wrong is the single most common URL bug there is. encodeURIComponent escapes the URL-structural characters / ? # & = along with everything else, which is correct when you are encoding one value to drop into a query string. encodeURI leaves that structure alone, which is correct when you are cleaning up an entire URL. Use the first on a whole URL and you get an unusable blob; use the second on a value containing an ampersand and you have just invented an extra parameter.

encodeURIComponent versus encodeURI, with the actual rule

The difference is small in code and large in consequence. Both escape spaces, non-ASCII characters, and unsafe punctuation. They differ on the eleven characters that give a URL its structure.

• encodeURIComponent escapes ; / ? : @ & = + $ , #. Everything becomes data. This is what you want for a single value: one query parameter, one path segment, one fragment.
• encodeURI leaves those eleven alone. This is what you want for a complete URL that merely contains awkward characters — for example a link with a space or an accented word in the path.

Two worked examples make it concrete. Suppose a search term is a/b & c=d. Encoded as a component it becomes a%2Fb%20%26%20c%3Dd, which survives as a single parameter value. Encoded with encodeURI it becomes a/b%20&%20c=d, and the receiving server now sees a path separator, a parameter boundary and a key-value pair that were never intended — a classic parameter-injection bug.

Now suppose you have the whole URL https://example.com/my page?q=1. encodeURI gives https://example.com/my%20page?q=1, still a working link. encodeURIComponent gives https%3A%2F%2Fexample.com%2Fmy%20page%3Fq%3D1 — correct only if that URL is itself being passed as a value, as with a redirect_uri parameter.

A useful heuristic: if the thing you are encoding will sit to the right of an = sign, use component mode. If it is the link itself, use full-URL mode. And if you are building a URL from parts, encode each part separately and then join them — never encode the assembled string.

What gets escaped, and what does not

Neither function escapes the unreserved characters defined by RFC 3986: A–Z, a–z, 0–9, and - _ . ~. Those are safe everywhere and never need encoding. encodeURIComponent additionally leaves ! ' ( ) * untouched, which is a quirk of the ECMAScript specification rather than of RFC 3986; some strict parsers prefer these escaped, and OAuth 1.0 signing in particular required it.

Non-ASCII characters are encoded as their UTF-8 bytes, one %XX per byte. So é becomes %C3%A9 — two escapes for one character — and an emoji becomes four. If you see a single %E9 where you expected %C3%A9, the producing system used Latin-1, and the value will decode to a replacement character or throw on a strict decoder.

A space has two possible encodings, and which is correct depends on where it sits. In a path it must be %20. In an application/x-www-form-urlencoded query string, + is also accepted and is what HTML forms actually submit. %20 is valid in both places, so this tool always produces %20 — it is the safer choice, and the only correct one outside a query string.

Where percent-encoding bugs actually bite

• OAuth and OpenID redirect URIs. The redirect_uri parameter is a whole URL used as a value, so it must be component-encoded. An unencoded ? or & in it splits the outer request apart, and providers reject the mismatch with an unhelpful error.
• Search and filter parameters. An ampersand inside a product name, an equals sign in a formula, a hash in a colour code — any of these silently creates a new parameter or truncates the value unless component-encoded.
• Signed URLs. AWS, Google Cloud and CDN signatures are computed over the exact encoded string. Encode differently from the signer — even just escaping * or not — and the signature fails to verify.
• Double encoding. Encoding an already-encoded string turns every % into %25, so %20 becomes %2520 and the user sees a literal %20 in their page. If your output contains %25 and you did not have a literal percent sign in the input, you have encoded twice.
• Encoding the whole thing. Component-encoding an assembled URL destroys it: the scheme separator, the slashes and the query delimiters all become data. Encode the parts, then join.