URL Encoding 101: Special Characters in Web Addresses

If you've ever searched Google and noticed that spaces in your query become %20 in the address bar, you've seen URL encoding in action. URL encoding (also called percent-encoding) is the mechanism that lets any data — including spaces, slashes, and special characters — travel safely inside a URL. This guide explains how it works and when to use it.

Why URLs Need Encoding

URLs are designed to be simple: a sequence of characters identifying a resource. But the world is messy — sometimes you need to send data that includes characters that are themselves URL syntax characters (/, ?, &), or non-ASCII characters (中文, émojis), or binary data.

URL encoding solves this by representing unsafe characters as a % followed by two hexadecimal digits — the character's byte value in UTF-8.

The Rules of URL Encoding

Characters that are SAFE (don't need encoding)

These characters can appear literally in a URL: A-Z a-z 0-9 - _ . ~ These are called "unreserved" characters and were defined in RFC 3986.

Characters that MUST be encoded

These are reserved for URL syntax and must be encoded when they appear as data:

• ! # $ & ' ( ) * + , / : ; = ? @ [ ]
• All non-ASCII characters (é, 中文, etc.)
• Space — becomes %20 (or + in query strings)
• Control characters, newlines, tabs

Query String Encoding vs. Path Encoding

Not all parts of a URL are encoded the same way. The encoding rules differ depending on which part of the URL you're in:

Query string (after the ?)

Use application/x-www-form-urlencoded. Spaces can be encoded as either %20 or + (historically the latter). Ampersands & separate key-value pairs and must be encoded as %26 when they appear inside a value.

https://example.com/search?q=coffee%20%26+tea&lang=en
# q = "coffee & tea"
# lang = "en"

Path (between slashes)

The path is /-delimited. Forward slashes within path segments must be encoded as %2F, otherwise they'll be interpreted as path delimiters. But the path separator / itself must NOT be encoded.

https://example.com/user/john%2Fdoe/profile
# The actual path segment is "john/doe"

Fragment (after #)

Fragments identify a section within a page. The hash itself is not encoded, but everything after it can be.

Common Encoding Mistakes

• Double encoding — Encoding something that was already encoded: %2520 instead of %20. This usually happens when a library encodes automatically and you also encode manually.
• Not encoding at all — Putting raw special characters in a URL. A space breaks the URL. An ampersand in a query value merges parameters unexpectedly.
• Encoding the wrong part — Encoding the = in a query parameter name or the ? that starts the query string. Only encode the values.
• Confusing encoding with encryption — URL encoding is not security. Encoded strings are trivially readable. Use HTTPS for security.

Real-World Example

Suppose you want to search for "coffee & tea recipes" with a rating of 4+ stars:

Base URL: https://example.com/search

Step 1: Build the query string
q:        coffee & tea recipes  → coffee%20%26%20tea%20recipes
rating:   4+ stars             → 4%2B%20stars

Step 2: Combine (note & separating params, not encoded inside values)
Result: https://example.com/search?q=coffee%20%26%20tea%20recipes&rating=4%2B%20stars

URL encoding is one of those small details that causes big bugs when done wrong. A missing %26 can merge two query parameters and return completely wrong data. Bookmark the URL Encoder and always validate your URLs before sending them into the wild.