Why There Are Three Different 'Correct' Ways to URL-Encode a Space

A space inside a URL can correctly become %20 or +, and both are right - just for two different, real standards that answer slightly different questions. There isn't one "URL encoding," there are three genuinely standard encodings that overlap enough to be confused and diverge enough that picking the wrong one silently breaks a value.

The three real conventions

Component encoding (RFC 3986, what encodeURIComponent implements) is for a single value going inside a URL - a query parameter, a path segment. It escapes a space to %20 and also escapes the characters that would otherwise be read as URL structure: & = ? / # among others, because those characters mean something specific if left raw inside a value. Whole-URI encoding (what encodeURI implements) is for an already-complete URL, and it deliberately leaves & = ? / # unescaped, because in a whole URL those characters are doing their structural job - separating the path from the query string, one parameter from the next - and escaping them would break the URL rather than protect it. Form encoding (application/x-www-form-urlencoded) is the older convention HTML forms use when submitted, and it encodes a space as + instead of %20, a real, separate historical standard, not a typo or a bug in whichever tool produces it.

Where mixing them up actually breaks something

The failure is usually silent. A value encoded with the form convention (space as +) decoded by something expecting component encoding will read the literal character + as part of the value instead of a space, and a search query "coffee shop" comes back as "coffee+shop" wherever it's displayed. A whole URL, already correctly assembled, run through component-level encoding a second time by mistake escapes its own & and = characters, turning a working link into one that no longer parses as a URL at all when the receiving system tries to split it back into path and query.

The reverse mistake is just as common: taking a whole, already-correct URL and leaving it unencoded when it needs to sit inside another URL as a value, on the assumption that "it's already a valid URL, so it doesn't need encoding." A valid URL and a valid value-inside-a-URL are different requirements - the first cares whether the URL parses on its own, the second cares whether the outer URL can tell where the value starts and ends. A URL can satisfy the first and fail the second at the same time.

A related, easily confused encoding

Percent-encoding and Base64URL - the encoding JWTs use - are two different things that share a name-adjacent reputation for being "the URL-safe one," and mixing them up produces garbled output rather than an error. Percent-encoding replaces individual unsafe characters with %XX sequences and leaves the rest of the text readable; Base64URL re-encodes the entire input into a different alphabet, with no readable characters left at all. If a decode attempt here produces nothing recognizable, it's worth checking whether the string was actually Base64 or Base64URL to begin with, not percent-encoded text - the Base64 tool is the one built for that case.

Why this tool implements exactly one of the three

This site's URL encoder implements component-level encoding only - encodeURIComponent/decodeURIComponent - because that is what a single value being placed inside a URL almost always needs, and it is the platform-native, zero-guesswork implementation for that exact job. It does not offer a form-encoding output or a whole-URI mode, because silently guessing which of the three you meant would be worse than not offering the choice at all - the one concession is a "Read + as a space" checkbox on Decode, for text that came from a form; if you genuinely need form-style +-for-space encoding, that is a different, separate convention this tool does not produce.

Everything you paste here stays in your browser - nothing is sent anywhere to be encoded or decoded.