URL Encoding Explained: Why Spaces Become %20
You've seen it in web addresses: %20 where a space should be, or %3D instead of an equals sign. That's URL encoding (also called percent-encoding), and while it looks like gibberish, it solves a real problem that keeps the web working. Here's what's going on.
Why URLs need encoding
URLs can only safely contain a limited set of characters — letters, digits, and a few symbols. Many characters have special meaning (? starts a query string, & separates parameters, / separates path segments) or aren't allowed at all (spaces). If you put those characters into a URL as-is, browsers and servers get confused. Encoding replaces them with a safe representation.
How it works
Percent-encoding replaces an unsafe character with a % followed by its two-digit hexadecimal byte value. A space is byte 32, which is 20 in hex — hence %20. An equals sign becomes %3D, an ampersand %26, and so on. Encode or decode any string instantly with our URL encoder and URL decoder.
A practical example
Suppose you want a search URL for "café & bar". The space and ampersand must be encoded:
https://example.com/search?q=caf%C3%A9%20%26%20bar
Notice "é" became %C3%A9 — non-ASCII characters are encoded as their UTF-8 bytes, which can be more than one percent-pair. The MDN percent-encoding reference covers the details.
Where it matters
- Query parameters: user input in search and forms must be encoded so special characters don't break the URL.
- APIs: passing values in a URL requires encoding to stay valid.
- Links with tracking: campaign URLs often carry encoded values.
Common pitfalls
Two big ones: double-encoding (encoding an already-encoded string, turning %20 into %2520) and forgetting to encode user input, which can break links or open security holes. When in doubt, decode a URL to check what it really contains.
Bottom line
URL encoding swaps unsafe characters for a % plus their hex byte value, so URLs stay valid no matter what they contain. Spaces become %20, special symbols get their own codes, and non-ASCII characters use their UTF-8 bytes. Encode user input, avoid double-encoding, and use a tool to check — and those cryptic percent signs stop being a mystery.
