Why URLs Break Without Encoding (and What Each Special Character Means)
By Marcus Vane · September 21, 2026 · Developer Tools
A space, an ampersand or a hash in the wrong place can silently break a link or split a query string. URL encoding exists to solve this, and the rules are simpler than they look.
A URL is a string with structure, and several of the characters that make up that structure, such as the slash, the question mark, the ampersand and the hash, also appear naturally in the data people want to put inside URLs. Without rules to distinguish structure from content, a search for "fish & chips" becomes a broken link the moment the ampersand is interpreted as a query parameter separator. URL encoding, also called percent encoding, is the mechanism that resolves the ambiguity.
Once you understand which characters are reserved and why, encoding stops feeling like random noise and becomes a predictable, mechanical step.
In this article:
- What URL encoding actually does
- The reserved characters and their roles
- Worked examples of encoding gone wrong
- When to encode and when not to
- Common mistakes
- FAQ: URL encoding edge cases
- Wrapping up
What URL encoding actually does
Percent encoding replaces a character with a percent sign followed by its two digit hexadecimal byte value. A space becomes "%20", an ampersand becomes "%26", and a hash becomes "%23". Any character can be encoded this way, but only characters that are unsafe or not allowed in a particular URL component must be encoded. The receiver decodes the sequence back to the original character before using the value, so the data round trips losslessly.
The reserved characters and their roles
- The slash "/" separates path segments. Encode it as "%2F" when it is part of a value, or it will be read as a path boundary.
- The question mark "?" starts the query string. Only one is structural; any further one must be encoded.
- The ampersand "&" separates query parameters. An unencoded ampersand in a value splits one parameter into two.
- The equals sign "=" pairs a parameter name with its value. An unencoded equals in a value confuses the parser.
- The hash "#" begins the fragment, which the server never sees. An unencoded hash truncates the URL at that point on the client.
- The space " " is not allowed in a URL at all and must be encoded, most commonly as "%20" or, in query strings only, as a plus sign.
- The percent "%" itself must be encoded as "%25" when it is literal data, or it will be read as the start of an encoded sequence.
Worked examples of encoding gone wrong
Example one: the ampersand in a search term
A search URL built as "example.com/search?q=fish & chips" sends two parameters to the server: "q" with value "fish " and a second parameter named " chips" with no value. The intended single query is lost. Encoding the value as "fish%20%26%20chips" sends one parameter "q" with the full value "fish & chips", which is what the user searched for.
Example two: the slash in a filename
A path segment containing a date, "example.com/files/2026/01/report", is read as four path segments. If the date is a single value that happens to contain slashes, like a category label "a/b", the URL must encode the slash as "example.com/files/a%2Fb" to keep it as one segment. Failing to do so routes the request to the wrong handler.
Example three: the hash that hides the rest
A link to a product with a colour code containing a hash, "example.com/item?colour=teal#5", is split at the hash. The server receives "colour=teal" and the "#5" becomes a fragment that the browser keeps locally. Encoding as "colour=teal%235" delivers the full value to the server. This is a common cause of silently truncated parameters.
When to encode and when not to
Encode a value immediately before placing it into a URL component, and encode for the specific component. A value placed in the path must encode slashes, but a value placed in the query string may leave slashes unencoded because they are not reserved there. The safest habit is to use the encoding function appropriate to the component: a path encoder for path segments and a query encoder for parameter values. Never encode a full URL string in one pass, because that encodes the structural characters too and produces a link to a single, meaningless path segment.
Common mistakes
- Double encoding, where an already encoded value is encoded again, turning "%20" into "%2520". Decode before re encoding, or encode only once at the source.
- Encoding the whole URL including its structure, which breaks the link entirely.
- Using a plus sign for spaces outside the query string. The plus is only a space in the query component; in the path it is a literal plus.
- Forgetting to encode the percent sign itself when it appears as data.
- Assuming the browser will fix it. Browsers often repair obvious errors in the address bar but do not reliably fix URLs embedded in HTML or JavaScript.
- Mixing encoded and unencoded values in the same parameter, which produces inconsistent parsing.
FAQ: URL encoding edge cases
Should I encode non ASCII characters like accents or other scripts?
Yes. Modern URLs are encoded as UTF 8, and each byte of a multi byte character is percent encoded. An "e" with an acute accent becomes "%C3%A9". Most encoding functions handle this automatically when given a string.
Why do some spaces appear as "%20" and others as "+"?
Both represent a space. The plus form comes from the older form encoding used in the query string, while "%20" is the general percent encoding. Use "%20" in paths and either in query strings, but be consistent within a single URL.
Is decoding always safe?
Decoding a value once is safe. Decoding twice can turn a legitimately encoded percent into an unexpected character, so decode exactly once at the point of use.
Wrapping up
URL encoding resolves the conflict between structure and content in a URL. Encode each value for the component it lives in, watch the ampersand, slash, hash and space in particular, and never encode a whole URL in one pass. Get that right and your links will carry any data without breaking.
Encode or decode any URL component instantly in your browser.
Try the URL Encoder / Decoder tool.
SwiftMultiTool — free online tools for everyone. Home · Blog · About · FAQ · Contact