URLs can only contain a limited set of ASCII characters, so anything else — spaces, accents, emoji, or the reserved separators that structure a URL — has to be percent-encoded. This tool encodes and decodes that representation entirely in your browser. This guide explains when to reach for component versus full-URL encoding, why a space is sometimes a + and sometimes %20, and how to read a decode error.

When to use encodeURIComponent vs encodeURI

The two functions differ only in which characters they protect. encodeURIComponent escapes everything except the unreserved set (letters, digits, and - _ . ! ~ * ' ( )), so reserved separators like / ? & = # are turned into %2F %3F %26 %3D %23. That is exactly what you want for a single piece of data — one query value, one path segment — because it guarantees the value cannot be misread as structure.

encodeURI is meant for a whole URL. It leaves the reserved characters that delimit a URL untouched, so https://x.com/a?b=c stays usable. The trade-off: it will not protect a value that itself contains a / or &. Rule of thumb: encode each value with component mode first, then assemble the URL; only use full-URL mode when you have a finished URL that merely contains a stray space or accent.

Reserved characters and the + vs %20 confusion

RFC 3986 calls these the reserved characters: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Inside data they must be escaped; as delimiters they must not be. The most common source of bugs is the space. Modern percent-encoding always writes a space as %20. But the older application/x-www-form-urlencoded format — what a browser produces when it submits an HTML form — encodes a space in the query string as +. So ?q=a+b and ?q=a%20b can both mean "a b". When you decode a form-style string, turn on Treat + as space; when you decode a path or a modern API URL, leave it off so a literal + stays a +.

Why decoding fails, and double-encoding

Decoding throws a URI malformed error when a % is not followed by exactly two hex digits (0–9 A–F). A literal percent sign in source text, like 50% off, is the usual culprit — it should have been encoded as %2520… no, as 50%25 off, where %25 is the escaped percent. The tool points at the position of the first bad sequence so you can locate it. The opposite hazard is double-encoding: if you encode a string that already contains %XX, the percent signs themselves get escaped and %20 becomes %2520. The tool detects already-encoded input and warns you to decode instead.

Privacy: every operation here runs locally with the browser's native encodeURIComponent, encodeURI, decodeURIComponent, and decodeURI. Nothing you paste — tokens, query strings, personal data — is ever sent to a server.