URL Encoding in Practice: What Gets Encoded and Why

An encoder has one job: take text that needs to travel inside a URL and rewrite every character the URL grammar cannot carry bare. Which characters change, how much non-ASCII text grows, and why a whole URL encodes differently from a single value — these are easier to see on real strings than to memorize.

One function, one job

The tool wraps a single standard pair: encodeURIComponent to encode, decodeURIComponent to reverse it. The encoder keeps only the characters a URL may carry anywhere — letters, digits, and - _ . ~ — and replaces every other character with a percent sign followed by the hexadecimal value of its UTF-8 bytes. A space becomes %20, an ampersand %26, a colon %3A. Decode mode runs the same machinery backwards: paste encoded text and get the original back, or a clear error if the sequence is malformed — decoding never silently guesses.

Watching three characters change

Encode "hello world & co" and you get hello%20world%20%26%20co. Exactly three characters were rewritten — the two spaces and the ampersand — while the other thirteen rode bare. The ampersand is the important one: it is legal text in a query value but fatal grammar in a URL, because it starts the next parameter. Left bare, "rock & roll" arrives as two parameters, rock and roll. Encoding at the boundary where a value enters the URL is what keeps one value one value. The full grammar this protects is laid out in URL Encoding: When %20 Matters.

Non-ASCII text grows

The %XX sequences hide bytes, not characters, so text outside plain ASCII grows more than you might expect. "café menu" encodes to caf%C3%A9%20menu — the é is two UTF-8 bytes, C3 A9, so it becomes six characters of output. Scripts that need three bytes per character roughly triple in length, which is why a Japanese or Arabic query string can look enormous in an analytics dashboard yet be perfectly normal. The underlying byte story is the same one everywhere in computing; How Text Encoding Works explains why é is two bytes at all.

A value is not a whole URL

Encode https://ex.com/a?b=1 and the tool returns https%3A%2F%2Fex.com%2Fa%3Fb%3D1 — colons, slashes and question marks all dressed. That looks wrong until you apply the rule: encode values, not addresses. It is exactly what you want when a URL is data — a redirect target inside a query parameter, a callback address — because otherwise the inner & would be read as splitting the outer query. It is what you do not want when you simply mean to link somewhere. The sibling function encodeURI exists for that second case: it preserves : / ? & = and escapes only what would otherwise break the address. Knowing which situation you are in is the whole skill.

Encoder or parser?

The two URL tools point in opposite directions. The encoder rewrites a piece of text so it survives inside one slot of a URL; the parser takes a complete URL and reports what each slot contains — scheme, host, path, query parameters, fragment. If you have a value destined for a URL, encode it. If you have a URL and want its contents out, parse it. They are inverses in spirit but not in function: encoding does not read structure, and parsing does not encode. For piles of already-encoded links — campaign URLs, log exports — a batch decoder unhides many strings in one pass, which is where double-encoded %2520 casualties get sorted out.

Try it yourself

Type "hello world & co" into the URL Encoder & Decoder and count which characters get dressed — then flip to Decode and bring the result back exactly. Encode a full URL to feel the value-versus-address difference, and paste any complete address into the URL Parser to see the structure that encoding protects. For a stack of encoded links at once, the URL Decode Batch unhides them in one go.