Why URLs Can't Contain Spaces (and What %20 Actually Means)

URLs have a strict character rulebook

The format of a URL is defined by an official technical specification (currently RFC 3986), and it reserves certain characters — spaces, ampersands, question marks, and several others — as structural punctuation with specific meaning inside a URL. A literal space or an unencoded ampersand inside a URL is ambiguous: is it part of your data, or does it mark where one part of the address ends and another begins? Percent-encoding resolves that ambiguity by representing those characters as a safe, unambiguous stand-in.

How percent-encoding actually works

A percent-encoded character is written as a % symbol followed by two hexadecimal digits representing that character's byte value. A space becomes %20 because 20 in hexadecimal is the ASCII code for a space. This is exactly why you'll sometimes see a URL like example.com/hello%20world instead of one with a literal space — the browser or server needed an encoding it could parse unambiguously.

The confusing exception: + vs. %20

Here's a genuine wrinkle that trips people up: in the query-string portion of a URL specifically (the part after a ?), a + symbol is often used to represent a space instead of %20, a convention inherited from older HTML form submission standards, not the core URL specification itself. This means the same "space" can legitimately be represented two different ways depending on which part of the URL it's in, which is a common source of subtle bugs when developers assume one encoding works everywhere.

Component encoding vs. full-URL encoding

This distinction matters practically: if you encode an entire URL using "component" encoding (meant for a single value), you'll also encode the slashes and colons that structure the URL itself, breaking it. Full-URL encoding is meant for exactly that case — it leaves structural characters like : / ? & alone and only encodes things like spaces and non-ASCII characters. Using the wrong mode for the situation is one of the most common URL-encoding mistakes developers make.

Try both modes yourself

Our URL Encoder/Decoder supports both component encoding (for a single value going into a query parameter) and full-URL encoding (for an entire address), so you can see exactly how each one treats the same input differently.