URL Encoding Explained: %20, %3A, and Why They Exist

If you've ever seen a URL with %20 or %3A in it, you've seen URL encoding. It's one of those things that's mostly invisible until it causes a bug. Here's how it works and where it matters in real development.

Why URLs Need Encoding

URLs are restricted to a specific character set defined in RFC 3986. Only unreserved characters can appear literally: letters (A-Z, a-z), digits (0-9), and four punctuation marks (-, _, ., ~). Everything else must be percent-encoded.

The restricted character set exists because URLs pass through many systems — browsers, proxies, servers, routers — and each has its own rules about which characters are safe to transmit. Encoding everything ensures the URL survives the journey intact.

How Percent Encoding Works

A percent-encoded character is written as %XX where XX is the character's hexadecimal UTF-8 value. A space (ASCII 32, or 0x20 in hex) becomes %20. A colon (ASCII 58, 0x3A) becomes %3A.

Common encodings you'll encounter:

• %20 — space
• %2F — forward slash /
• %3F — question mark ?
• %3D — equals sign =
• %26 — ampersand &
• %40 — at sign @
• %23 — hash #

Reserved vs Unreserved Characters

Some characters have special meanings within URL structure: / separates path segments, ? begins the query string, = separates key from value, & separates query parameters, # begins the fragment. These are "reserved" characters.

If you use a reserved character literally in a URL component where it doesn't have its structural meaning — for example, a query parameter value containing an & — you must encode it. Otherwise the URL parser misinterprets the structure.

URL Encoding vs Form Encoding

There's a subtle difference between URL encoding (RFC 3986) and HTML form encoding (application/x-www-form-urlencoded). Form encoding encodes spaces as + rather than %20, and has slightly different rules for which characters get encoded. This causes bugs when people mix the two — a + in a URL-encoded string is literally a plus sign, but in a form-encoded string it's a space.

Common Developer Mistakes

Double encoding: encoding an already-encoded string. %20 becomes %2520 (the % gets encoded to %25). The decoded result is the string %20 rather than a space. This happens when you encode a full URL instead of encoding individual components before assembling the URL.

Encoding path separators: if you URL-encode a file path like /home/user/file.txt as a query parameter value, the slashes must be encoded (%2F). If they're not, the server sees additional path segments rather than a query value containing slashes.

Not encoding at all: user-provided strings (search queries, usernames, any user input) must be encoded before being inserted into URLs. Failing to do this is both a functional bug (special characters break the URL) and often a security issue (URLs are a vector for injection in link-based attacks).

Use our URL Encoder/Decoder to encode or decode any string — handles both RFC 3986 and form encoding.