Why URLs Need Encoding at All
A URL can only contain a restricted set of ASCII characters, and a handful of those carry structural meaning. The ? starts a query string, & separates parameters, / divides path segments, # begins a fragment. When a value you want to transmit contains one of those characters, something has to distinguish "this is data" from "this is syntax".
Percent-encoding is that mechanism. A character is replaced by % followed by its byte value in hexadecimal: a space becomes %20, an ampersand becomes %26, a slash becomes %2F.
Three Classes of Character
Everything in a URL falls into one of three groups, and knowing which is which explains every encoding decision.
- Unreserved: letters, digits, and
- . _ ~. Never need encoding, and encoding them anyway is legal but pointless. - Reserved:
: / ? # [ ] @ ! $ & ' ( ) * + , ; =. These have structural roles. They must be encoded when they appear inside a value and left alone when they are doing their structural job. - Everything else: spaces, accented letters, CJK characters, emoji. Always encoded.
That middle group is the entire reason this tool has two modes.
Full URL or Single Component
Component mode encodes reserved characters. Use it for one value, a search term, a parameter, a filename, that will be placed into a URL. Feeding it a whole URL destroys the URL, because the :// and ? and & that make it a URL all get encoded.
Full URL mode preserves the syntax characters and encodes only what cannot appear literally. Use it on a complete address containing spaces or non-ASCII characters. It will not, however, encode an ampersand inside a parameter value, and that is a real failure mode rather than a limitation.
The classic bug: a search for coffee & tea encoded in full-URL mode produces ?q=coffee%20&%20tea, and the receiving server reads it as two parameters, q=coffee and an empty tea. Encode each value with component mode, then assemble the URL from the encoded pieces.
The Space Problem
Spaces have two encodings and they are not interchangeable. In a URL path a space is %20. In a query string, the older HTML form encoding represents it as +, and %2B is then required for a literal plus sign.
This is why a plus sign in a search term sometimes vanishes: it was transmitted literally, and the receiving side decoded it as a space. Percent-encoding the plus as %2B is what preserves it. Most modern frameworks handle this, but hand-built query strings routinely get it wrong.
Unicode Goes Through UTF-8 First
Percent-encoding operates on bytes, not characters, so anything outside ASCII is converted to UTF-8 first and each resulting byte is encoded separately. A single accented character becomes two escape sequences; most CJK characters become three; an emoji becomes four.
That is why an encoded URL containing Korean or Chinese text looks so much longer than the original. It is not inefficiency, it is one escape sequence per byte, and those characters are simply multi-byte.
Domain names work differently. They cannot carry percent-encoding, so internationalised domains use Punycode instead, converting non-ASCII names into an ASCII form beginning xn--. Encoding applies to the path and query, not the host.
Everything runs in your browser using the standard encodeURI and encodeURIComponent functions, so nothing you paste is transmitted or stored.