The Problem URL Encoding Actually Solves
URLs are supposed to be plain text, but the underlying protocol they travel over was never designed to handle every character a human might want to put in a web address. Spaces, ampersands, question marks, hash symbols — all of these mean something specific in URL syntax, and if you put them in raw, the URL either breaks outright or gets interpreted completely differently from what you intended.
Think about a search query like "coffee & tea shops near me". If you just dropped that straight into a URL, the ampersand would be read as the start of a new query parameter, not as part of your search text. The browser, or worse, the server on the other end, would have no reliable way to know you meant the literal character "&" rather than a parameter separator. URL encoding exists to remove that ambiguity entirely.
How Percent-Encoding Actually Works
The mechanism is simpler than it looks once you see it laid out. Every character that isn't considered "safe" in a URL gets replaced with a percent sign followed by its hexadecimal code. A space becomes %20. An ampersand becomes %26. A question mark becomes %3F.
So that earlier search, "coffee & tea shops near me", becomes coffee%20%26%20tea%20shops%20near%20me once encoded. It looks messier to a human, but to a server parsing the URL, it's now completely unambiguous. There's no character in that string that could be mistaken for part of the URL's own structure.
| Character | Encoded As | Why It Needs Encoding |
|---|---|---|
| Space | %20 (or +) | Spaces aren't allowed in URLs at all |
| & | %26 | Separates query parameters |
| = | %3D | Separates parameter keys from values |
| ? | %3F | Marks the start of the query string |
| # | %23 | Marks the start of a URL fragment |
| / | %2F | Separates path segments |
| + | %2B | Can be misread as a space in some contexts |
One small wrinkle worth knowing: in the query string portion of a URL specifically, a plus sign (+) is often used as an alternative way to represent a space, a legacy convention from old HTML form submissions. This is why you'll sometimes see search URLs with + between words instead of %20. Both are technically valid in that context, but they're not interchangeable everywhere in a URL — a + in the path portion of a URL means a literal plus sign, not a space.
Where This Actually Trips People Up
Sharing Links With Special Characters
You copy a link from your browser's address bar — maybe a Google Maps location or a search result — and paste it into a chat app or email. Sometimes the app you're pasting into mangles the link if it contains unencoded special characters, especially older messaging systems or simple link-preview tools that weren't built to handle every edge case.
Building Links Programmatically
If you're a developer constructing URLs in code — say, building a search link by concatenating a user's input directly into a URL string — forgetting to encode that input is a common and genuinely dangerous mistake. Beyond breaking the link, unencoded user input dropped directly into a URL can open the door to injection-style vulnerabilities depending on how the receiving server processes it.
International Characters and Emoji
Non-ASCII characters — accented letters, characters from non-Latin scripts, emoji — all need encoding too, and they encode to longer, more complex sequences than simple ASCII characters since they're represented in UTF-8 first and then percent-encoded byte by byte. A single emoji can turn into a string of six or more percent-encoded characters.
Double Encoding
This one catches developers specifically. If you encode a URL that's already encoded, you get garbage — the % symbol itself gets encoded to %25, so %20 (an encoded space) becomes %2520 if you run encoding on it twice. This is a surprisingly common bug in systems where a URL passes through multiple layers of processing, each one assuming it needs to encode the string itself.
Encoding and Decoding URLs with DocsConverter
Our free URL Encoder/Decoder handles both directions instantly in your browser. Paste a raw string with spaces and special characters, and it gives you the properly percent-encoded version ready to use in a URL. Or paste an encoded URL you've received from somewhere and it decodes it back into readable text, which is genuinely useful when you're trying to figure out what a long, cryptic-looking URL actually contains.
This is particularly handy when you're debugging an API request that isn't working as expected. Pasting the query string into a decoder often immediately reveals the problem — maybe a parameter value got double-encoded somewhere in your code, or a character you assumed was safe actually needed encoding and wasn't getting it.
Component Encoding vs. Full URL Encoding
There's a distinction worth understanding if you're writing code that builds URLs: encoding an entire URL is different from encoding one component of it, like a single query parameter value. If you encode an entire URL using a strict component-encoding function, you'll accidentally encode the slashes and colons that are supposed to remain as structural characters — turning https://example.com into garbage.
This is why JavaScript provides two different functions: encodeURI() for encoding a full URL while leaving structural characters intact, and encodeURIComponent() for encoding a single piece — like a query parameter's value — where every special character, including slashes, should be encoded. Using the wrong one is an extremely common source of broken-link bugs.
A Quick Mental Model That Actually Helps
If you remember nothing else from this article, remember this: URL encoding exists because some characters have a job to do in a URL's structure, and other characters are just data. Encoding is how you tell the difference between "this slash is separating folders" and "this slash is part of the actual content the user typed." Anytime you're putting unpredictable human input — search terms, names, addresses — into a URL, that input needs encoding. Anytime you're writing the fixed structural parts of a URL yourself, those stay as-is.
Frequently Asked Questions
Why do some URLs use + and others use %20 for spaces?
Both represent a space, but in different contexts. %20 is the standard percent-encoding for a space and works everywhere in a URL. The + convention is specific to the query string and comes from older HTML form-encoding standards (application/x-www-form-urlencoded). Outside the query string, a + means a literal plus sign.
Is it safe to put any text into a URL if I encode it first?
Encoding makes the text syntactically safe for the URL structure, but it doesn't automatically make it safe from a security standpoint if that text is later used elsewhere, like inserted into a database query or displayed on a page without further sanitization. Encoding solves the URL transport problem specifically, not every downstream security concern.
Why does my URL look fine in the browser but break when I share it?
Browsers are quite forgiving and will often display and even follow a URL with unencoded special characters, silently encoding it behind the scenes. Other systems — older apps, certain APIs, command-line tools — are much stricter and will fail outright on the same unencoded URL. This is exactly why encoding the URL properly before sharing it, rather than relying on the browser's leniency, is the safer habit.
What's the difference between URL encoding and Base64 encoding?
They solve different problems. URL encoding makes text safe to include inside a URL's structure. Base64 encoding converts binary data (or any data) into a text-safe representation, commonly used for things like embedding images in data or encoding authentication tokens. They're not interchangeable.