URL Encoding: Why Your Links Break (And How to Fix Them Forever)
Published: July 10, 2025 · 6 min read
You've seen them — those URLs full of %20, %26, and %E4%B8%AD. They look like gibberish, but they're actually one of the most important (and misunderstood) mechanisms of the web. URL encoding — also called percent-encoding — is the reason you can send a search for "café & croissant" or type a Chinese address into your browser without everything falling apart.
But when URL encoding goes wrong, the results are maddening: broken links, unclickable URLs in emails, search queries that return nothing. Let's understand why this happens and how to fix it for good.
Why URLs Need Encoding
URLs have a strict set of allowed characters. According to the internet standard (RFC 3986), a URL can only contain:
- Unreserved characters: A-Z, a-z, 0-9, hyphen (-), underscore (_), period (.), and tilde (~)
- Reserved characters: Characters that have special meaning in URLs, like
?(starts query string),&(separates parameters),=(assigns values),#(fragment identifier),/(path separator)
Everything else — spaces, accented characters, Chinese characters, emoji, even the < and > signs — is technically illegal in a raw URL. If you try to use these characters without encoding, one of two things happens: the browser guesses what you meant (and sometimes guesses wrong), or the URL simply breaks.
URL encoding solves this by representing unsafe characters as % followed by two hexadecimal digits representing the character's byte value in UTF-8. For example, a space becomes %20, and the ampersand (&) becomes %26.
Common URL Encoded Characters — Quick Reference
| Character | Encoded Form | Why It Needs Encoding |
|---|---|---|
| Space | %20 (or + in form data) | Not allowed in URLs |
& | %26 | Reserved — separates query parameters |
# | %23 | Reserved — starts fragment identifier |
? | %3F | Reserved — starts query string |
= | %3D | Reserved — assigns parameter values |
/ | %2F | Reserved — path separator |
@ | %40 | Reserved — used in authority section |
: | %3A | Reserved — port/protocol separator |
+ | %2B | Represents space in form-encoded data |
| 中 (Chinese) | %E4%B8%AD | Non-ASCII — UTF-8 encoded |
| é | %C3%A9 | Non-ASCII — UTF-8 encoded |
| 😀 | %F0%9F%98%80 | Emoji — multi-byte UTF-8 |
encodeURI vs encodeURIComponent: The JavaScript Trap
If you're a developer working with JavaScript, you've likely encountered two similar-looking functions: encodeURI() and encodeURIComponent(). They are not the same, and using the wrong one is a common source of bugs.
encodeURI() is designed for encoding an entire URL. It preserves characters that have syntactic meaning in a URL — like /, ?, &, #, and = — so the URL's structure remains intact. Use this when you have a complete URL string that may contain non-ASCII characters.
encodeURIComponent() is designed for encoding individual query parameter values. It encodes everything except A-Z, a-z, 0-9, and - _ . ! ~ * ' ( ). This includes /, &, =, and ?. Use this when you're building query strings programmatically.
Here's the classic mistake:
encodeURI("https://example.com/search?q=coffee & tea")
Result: https://example.com/search?q=coffee%20&%20tea
Looks okay, right? But the & wasn't encoded — so the server interprets "tea" as a separate query parameter, not part of the search term. The correct approach:
"https://example.com/search?q=" + encodeURIComponent("coffee & tea")
Result: https://example.com/search?q=coffee%20%26%20tea
Now the & is properly encoded as %26, and the server correctly interprets the entire phrase as a single search term.
Before and After: URL Encoding in Action
Before (broken):https://myshop.com/products?name=café & croissant&category=pastry#top
This URL has multiple problems: the space and ampersand break the query string, the accented "é" might not be handled correctly, and the fragment is ambiguous.
After (encoded):https://myshop.com/products?name=caf%C3%A9%20%26%20croissant&category=pastry#top
The é becomes %C3%A9, the space becomes %20, and & becomes %26 — all properly encoded so the URL works universally.
Common Pitfalls to Avoid
- Double encoding: Encoding a string that's already partially encoded turns
%20into%2520(because%itself gets encoded as%25). The result is a broken URL. Always know whether your input is already encoded before applying encoding. - Forgetting query parameters: Building URLs by string concatenation without encoding is the #1 source of broken links. If a user types
Red & Blueinto a search box and your code builds?q=Red & Blue, the server sees two parameters:q=RedandBlue=. - Encoding the entire URL with encodeURIComponent: This turns
https://example.com/pathintohttps%3A%2F%2Fexample.com%2Fpath, which is no longer recognizable as a URL. UseencodeURIfor complete URLs. - Mixing
+and%20for spaces: Inapplication/x-www-form-urlencodeddata (HTML form submissions), spaces are encoded as+. In other parts of a URL, spaces should be%20. Using+in a raw URL path can cause confusion.
Fix Your URLs Today
URL encoding isn't glamorous, but it's foundational. Every broken link, every mistyped ampersand, every non-ASCII character that vanishes — they're all URL encoding problems in disguise. The good news is that once you understand the rules, the fixes are straightforward.
Need to encode or decode a URL right now? Use our free URL Encoder / Decoder — paste any string and instantly see its properly encoded (or decoded) form, with support for both encodeURI and encodeURIComponent modes.