URL Encoding Explained: When to Use encodeURIComponent vs encodeURI

By the Super Simple Digital Tools Team · Updated June 2026 · Text & Developer

Every web address is restricted to a small, safe alphabet. A URL can only reliably contain letters, digits, and a handful of punctuation marks; anything else, from a space to an ampersand to an emoji, has to be translated into percent-encoding before it can ride along inside the link. Percent-encoding works by taking the byte value of a character in UTF-8 and writing it as a percent sign followed by two hexadecimal digits. That is why a space shows up as %20 and why a literal question mark inside a value becomes %3F instead of being mistaken for the start of a query string.

RFC 3986, the specification that governs URLs, sorts characters into three buckets. Unreserved characters (the letters, digits, and - . _ ~) can appear as-is. Reserved characters such as : / ? # [ ] @ ! $ & ' ( ) * + , ; = carry structural meaning, marking where the path ends, where the query begins, and how parameters are separated. Everything else, including spaces, control characters, and non-ASCII text, must always be encoded. The whole point of an encoder is to convert reserved or unsafe characters into their %xx form when they appear as data rather than as structure.

This is where the two encoding modes matter. encodeURIComponent is the aggressive option: it encodes the reserved characters too, which is exactly what you want for a single piece of a URL such as one query value or one path segment. If a user types Jack & Jill into a search box, encoding the value turns the ampersand into %26 so the server does not read it as the boundary between two parameters. encodeURI is the gentle option that preserves the reserved characters, because it assumes you are handing it an entire, already-assembled URL whose slashes and colons should survive.

The classic mistake is choosing the wrong mode and corrupting the address. Run a complete URL through component mode and its https:// turns into https%3A%2F%2F, breaking the link. Run only the value through full-URI mode and an embedded & can still split your query string in two. The other classic bug is double-encoding: feeding already-encoded text back into the encoder, so % becomes %25 and the recipient ends up decoding gibberish. When in doubt, decode first to see the raw value, fix it, then encode exactly once.

A reliable workflow is to build URLs from the inside out. Start with the fixed structure (scheme, host, path), then encode each dynamic value with component mode and slot it into place, rather than concatenating raw user input and encoding the whole thing at the end. This tool lets you do that piece by piece: paste a value, encode it, and drop the clean result into your link. Because it runs in your browser, you can also use it to decode logged or shared URLs and read exactly what they contain before you trust them.

Try it now: Open the URL Encoder / Decoder →

Quick tips

Use component mode (encodeURIComponent) for individual query values and path segments; use full-URI mode (encodeURI) only on a complete, already-structured URL.
If you see %25 scattered through your output, you double-encoded. Decode until the text is readable again, then encode just once.
Prefer %20 for spaces in the path and query; reserve the plus sign for HTML form (application/x-www-form-urlencoded) payloads where + means space.
Decode any link before you click or trust it to reveal redirect targets, tokens, or parameters that a long string of %xx codes is hiding.

The URL Encoder / Decoder is free to use as often as you like — no signup required.