← Blog

URL Encoding Explained: Why URLs Break and How to Fix Them

September 6, 2026 · 6 min read

Every web address you click is really a promise: a string of characters that must survive being typed, copied, pasted into an email, and parsed by a browser. Most of the time the promise holds. The moment a URL contains a space, an accented letter, an emoji, or a stray ampersand, though, the address can silently break — and the link you shared stops working for everyone else.

This guide explains why URLs are so fragile, how percent-encoding makes them safe again, and when you should reach for an encoder or decoder instead of guessing.

What is percent-encoding?

Percent-encoding (also called URL encoding) is the rule set that lets a web address carry characters it was never designed to hold. The original URL standard allowed only a small set of safe characters: uppercase and lowercase letters, digits, and a few punctuation marks like the hyphen, underscore, period, and tilde. Anything else — a space, an ampersand, a slash inside a value, or a non-English letter — has to be translated into a safe form before it can go into a URL.

The strictness exists because a URL is not just a label; it is a small piece of syntax. Browsers, servers, and proxies all read it, and many characters carry structural meaning. A space has no reserved meaning at all — it is simply not a legal character in an address, so anything that meets one will either reject the link or guess at what you meant. Guessing is how links get mangled.

How the %XX scheme works

The rule is simple. Any character that is not safe is replaced by a percent sign followed by two hexadecimal digits that spell out the character's byte value. Hexadecimal, or hex, just means base 16, using the digits 0-9 and the letters A-F.

A space has the byte value 32 in decimal, which is 20 in hexadecimal, so it becomes %20. An exclamation mark is %21, a question mark is %3F, and a percent sign itself — which must be encoded so it is not read as the start of an escape sequence — becomes %25.

That is the entire trick: read the two hex digits as the numeric code of a character and you can decode any percent-encoded string by hand. Because the process is fully reversible, the same scheme works in both directions.

Reserved vs. literal: which characters need encoding

Not every special character is treated the same, and the distinction is where most confusion starts. The reserved characters — &, #, ?, =, and / among them — have a job to do inside a URL's structure. The ? starts the query string, & separates one parameter from the next, = pairs a name with its value, # marks a fragment, and / separates path segments.

The rule of thumb is simple: if a character is playing its structural role, leave it alone. If it is part of the actual data you are sending — a question mark inside a search term, an equals sign in a password field, an ampersand in a company name — it must be percent-encoded, or the browser will misread your data as syntax and split the URL in the wrong place.

Safe characters — letters, digits, and the hyphen, underscore, period, and tilde — can always stay as they are. Reserved and unsafe characters should be encoded whenever they are not being used as separators.

Spaces: %20 vs. the plus sign

A space is the single most common reason a URL breaks, and it has two accepted encodings that are not interchangeable. In the path portion of a URL — everything before the question mark — a space must be written as %20. There is no shortcut.

Inside a query string, the rules relax. When a browser submits an HTML form the traditional way, it encodes every space as a plus sign, and the server knows to turn that plus back into a space when it reads the value. So ?q=hello+world and ?q=hello%20world mean the same thing to a form handler.

The catch is that the plus convention only applies inside the query string. If you use a plus sign in a path, it is treated as a literal plus sign, not a space. When in doubt, %20 is always safe; the plus sign is a query-string-only shorthand.

Non-ASCII characters and UTF-8

The original URL alphabet is strictly ASCII, which leaves out most of the world's writing systems. The solution is to convert non-ASCII text into bytes using UTF-8 — the standard encoding that can represent every character — and then percent-encode each byte.

That is why an accented letter, a symbol like the euro sign, or an emoji becomes a run of several percent codes rather than a single %XX. One emoji can turn into four bytes, and therefore four %XX sequences, all produced automatically by the browser when you follow a link.

This is also why decoding matters. If a percent-encoded string is decoded with the wrong assumption about its encoding, the original characters come back garbled. Decoding a UTF-8-encoded URL back to UTF-8 text restores exactly what was sent.

How to use the URL Encoder / Decoder

You do not need to memorize the hex table. The URL Encoder / Decoder on AITool.red does the conversion instantly in your browser, with nothing uploaded anywhere.

  1. Paste or type your URL or text into the top input box.
  2. Click Encode to percent-encode it, or Decode to turn a percent-encoded string back into readable text.
  3. The result appears in the output box below. Click Copy result to copy it.
  4. Use Swap to move the output back into the input, which is handy for confirming a round trip is lossless.

If you paste something with a broken percent sequence — like a stray percent sign that is not followed by two hex digits — the decoder reports an error instead of silently mangling your data.

FAQ

What is the difference between %20 and + for spaces?

Both represent a space, but they are used in different places. %20 is the universal form that works anywhere, while the plus sign is only treated as a space inside a query string, after the question mark.

Which characters must be percent-encoded in a URL?

Any character that is not a safe ASCII letter, digit, or allowed symbol must be percent-encoded when it is meant as literal data. That includes spaces, non-ASCII letters, and reserved characters such as the question mark, hash, equals sign, and slash when they are not serving as the URL's own syntax.

Why do non-ASCII characters become percent codes in a URL?

URLs are built for a small set of ASCII characters. Any non-ASCII text, such as accented letters or emoji, is converted to UTF-8 bytes first, and each byte is then written as a percent code, which lets the original text be recovered exactly when it is decoded.

Need to fix a broken link right now? Open the URL Encoder / Decoder — free and local to your browser.