What Is URL Encoding and Why Do Spaces Become %20?

You paste a link into a browser and notice it's full of percent signs and numbers — %20, %2F, %40. Or you search for something with an ampersand in it and watch the URL turn into what looks like a cipher. This is URL encoding, and once you understand why it exists, it makes complete sense.

Why URLs Can't Just Use Any Character

A URL (Uniform Resource Locator) is a structured string that follows strict rules. It has reserved characters that carry specific meaning: ? starts a query string, & separates parameters, # marks a fragment, / separates path segments, and so on.

If you tried to pass a literal & character as part of a search query, the URL parser wouldn't know whether it was part of your data or a separator between two different parameters. Spaces present a similar problem — a space in a URL is technically invalid because URLs were designed to be transmitted in environments where spaces could cause parsing errors.

URL encoding (also called percent encoding) solves this by replacing problematic characters with a safe representation that the URL parser can read unambiguously.

How It Works

Every character in a URL can be represented by its ASCII code — a number from 0 to 127. URL encoding takes a character, finds its hexadecimal ASCII value, and writes it as a percent sign followed by two hex digits.

A space has an ASCII code of 32, which is 20 in hexadecimal. So a space becomes %20. An ampersand is ASCII 38, which is 26 in hex — so it becomes %26.

Common Characters and Their Encoded Forms

Character	Meaning in URL	Encoded Form
space	Invalid in URLs	%20 (or + in form data)
&	Parameter separator	%26
=	Key-value separator	%3D
?	Query string start	%3F
#	Fragment identifier	%23
/	Path separator	%2F
@	Username/password separator	%40
+	Sometimes used for space	%2B

A Real-World Example

Say you're building a search feature and the user types: coffee & tea

You need to pass this as a URL parameter. Unencoded, the URL would look like:

The parser sees two separate parameters — q=coffee and tea — and the space causes a malformed URL. After encoding:

Now the parser reads it correctly as a single parameter with the value "coffee & tea".

%20 vs + for Spaces

You might notice that spaces are sometimes encoded as + instead of %20, particularly in form submissions. This comes from the older application/x-www-form-urlencoded standard, which used + to represent spaces. Both are valid in query strings, but %20 is more universally correct and is the right choice in URL paths.

Non-ASCII Characters

What about characters outside the basic ASCII set — accented letters, emoji, non-Latin scripts? These are first converted to their UTF-8 byte representation, and then each byte is percent-encoded. The letter é (e with an accent) is two bytes in UTF-8, producing %C3%A9. An emoji might produce a string of four percent-encoded bytes.

This is why URLs containing Japanese, Arabic, or emoji characters can look extremely long and cryptic — every non-ASCII character expands into multiple encoded bytes. The characters are faithfully preserved, just in a format that URL parsers can handle.

When You'd Need to Encode or Decode Manually

Most of the time, browsers and frameworks handle URL encoding for you automatically. But there are practical situations where you'd want a manual encoder/decoder:

• Inspecting a URL parameter to see what it actually contains
• Building a URL string in a script without a URL library
• Debugging an API call where a parameter value isn't being parsed correctly
• Working with legacy systems that don't handle encoding automatically
• Encoding a string before embedding it in a query parameter