URLs can only safely contain a limited set of characters. Everything outside that set — spaces, accented letters, symbols like & or ? when they appear inside a value rather than as syntax — has to be re-encoded before it can travel inside a URL without being misread. That re-encoding is what "URL encoding" (also called percent-encoding) actually is.
Why %20 and not a literal space
A URL's structure is defined by specific characters: : separates scheme from the rest, / separates path segments, ? starts the query string, & separates query parameters, and so on. A raw space inside a URL is genuinely ambiguous — is it part of a value, or does it terminate the URL? Percent-encoding resolves the ambiguity by representing any character outside the safe set as % followed by its two-digit hexadecimal byte value:
space → %20 (0x20)
& → %26 (0x26)
? → %3F (0x3F)
é → %C3%A9 (UTF-8 encodes é as two bytes)Non-ASCII characters like é get encoded as multiple %XX sequences because they're first converted to their UTF-8 byte representation, then each byte is percent-encoded individually.
The "unreserved" characters that never need encoding
RFC 3986 defines a small set of characters as always safe in a URL, needing no encoding under any circumstance: uppercase and lowercase letters, digits, and four symbols — -, _, ., and ~. Everything else is either reserved (has structural meaning, like / and ?) or unsafe, and gets encoded when it appears as literal data rather than as URL syntax.
The + vs %20 confusion
You'll sometimes see a space represented as + instead of %20 — that's not an error, it's a different, older convention: application/x-www-form-urlencoded, the format browsers use for classic HTML form submissions. It's a separate spec from general URL/URI percent-encoding, and the two aren't interchangeable — a + in a query string coming from a form submission means space, but a literal + character in arbitrary URL-encoded data means a literal plus sign. This is exactly the ambiguity our URL Decode tool avoids by implementing strict percent-decoding (decodeURIComponent) rather than guessing which convention applies.
encodeURIComponent vs encodeURI
JavaScript actually has two different built-in encoders, and picking the wrong one is a common source of broken URLs:
encodeURIComponent— encodes aggressively, treating everything outside the unreserved set as data to protect. Use this for a single value going into a query parameter or path segment (a search term, a filename).encodeURI— encodes more conservatively, leaving structural characters like/,?, and&alone, because it assumes you're encoding an entire URL that already has its structure in place.
Running a whole URL through encodeURIComponent by mistake will mangle its own structure — encoding the / and ? that are supposed to remain structural. Our URL Encoder uses encodeURIComponent deliberately, since encoding a single value (not an entire pre-built URL) is the overwhelmingly common real-world use case.