What is URL encoding (and why spaces turn into %20)?

You see a web address full of %20, or a search link where every space became a percent sign and two digits, and it looks like the URL broke. It didn’t. That’s URL encoding doing its job, and once you know the one rule behind it, the address reads as plainly as the words you typed. This matters because a single unencoded character can quietly send a link to the wrong place, or drop half of your search term.

TL;DR: URL encoding, also called percent-encoding, replaces characters that are unsafe or have a special meaning in a web address with a percent sign and the two-digit hex value of their byte. That’s why a space becomes %20 and an ampersand inside a value becomes %26. It’s fully reversible and not encryption, so anyone can decode it.

Why URLs only allow a small set of characters

A URL has to survive being printed, typed, copied, and passed between systems that were never built together, so it can only use a small set of characters reliably. The safe set is the letters A to Z and a to z, the digits 0 to 9, and four marks: hyphen, period, underscore, and tilde. Everything else risks being misread on the way.

The trouble is that the text you want in a URL rarely stays inside that set. Search terms have spaces. Names have accents. Values carry punctuation. A space in particular has no place in a raw URL at all, and if it slips through, some systems trim it, some break the link, and some split the address in two. So instead of hoping every system treats an odd character the same way, URL encoding rewrites the risky ones into a form everything already understands.

The percent rule, byte by byte

Percent-encoding is one rule applied over and over. Take an unsafe character, find the numeric value of its byte, write that number in hexadecimal, and put a percent sign in front. The percent sign is the flag that says “an encoded byte follows,” and the two digits are the value.

Walk it through for a space. In the character table every character has a number, and a space is number 32. Written in hex (base 16), 32 is 20. Stick a percent sign on the front and you get %20. Same steps for the others:

Character	Byte number	Hex	Encoded
space	32	20	%20
&	38	26	%26
#	35	23	%23
?	63	3F	%3F
=	61	3D	%3D
+	43	2B	%2B

Because the rule is mechanical, it runs in reverse just as cleanly. Decoding scans for a percent sign, reads the next two digits, and puts the original byte back. No guessing, no key. That’s why a URL encoder and decoder at dev.hivly.net can convert a string either way in one pass and hand you back an exact match.

What happens to é and other non-ASCII letters

Here is where the byte detail earns its keep. Plain English letters are one byte each, so they map to one percent code. But an accented letter like é isn’t a single byte on the modern web. URLs encode text as UTF-8, and in UTF-8 the letter é is two bytes: C3 and A9. Each byte gets its own percent code, so é becomes %C3%A9, not a single % group.

You can watch this happen with any non-English character. One visible letter can turn into two, three, or four percent codes, one per UTF-8 byte. So if you decode a URL and a single accented letter looks like a run of percent codes, nothing is wrong. That’s just the letter spelled out in its UTF-8 bytes.

Reserved characters versus characters that just need escaping

Here’s the part that trips people up. Some characters aren’t banned, they’re reserved, which means they carry structural meaning in a URL. The question mark starts the query string. The ampersand separates one parameter from the next. The equals sign ties a name to its value. The slash splits the path, and the hash marks a fragment. These are allowed precisely because a URL needs them to mark out its own parts.

So a character can be in a URL for two different reasons, and that changes whether you encode it. When a slash separates folders in the path, it stays a slash. When an ampersand separates two query parameters, it stays an ampersand. You only encode a reserved character when it sits inside a value and you want it treated as plain text instead of structure. Everything outside the safe set, like spaces and accents, always gets encoded no matter where it sits.

Why you encode values but not the delimiters

Think of a query string as a form with labelled slots, and the reserved characters as the labels. The shape is ?name=value&name=value, where the question mark, equals signs, and ampersands hold the structure. Those delimiters have to stay raw, because they’re what tells the receiving system where one piece ends and the next begins. Encode them and you erase the shape.

The data you drop into each slot is a different story. Say a search value is tom & jerry. Paste it in raw and the ampersand reads as a separator, so the system thinks you sent two parameters and cuts your value in half. Encode that inner ampersand as %26 and it stays part of the value, a literal ampersand instead of a divider. Same for an equals sign or a slash that belongs inside the value. The rule in practice: leave the delimiters that build the URL alone, encode the contents you pour into them.

Decode a messy URL yourself

Here’s a URL you can work through by hand. Nothing about it is broken:

https://shop.example.com/search?q=tom%20%26%20jerry&sort=price%2Basc&note=caf%C3%A9

Take it left to right. The path is plain up to the ?, which starts the query string. Then three parameters, separated by the raw & between them:

• q=tom%20%26%20jerry decodes to q = tom & jerry. The %20 are spaces, and %26 is a literal ampersand inside the value, so the whole search term stays in one piece.
• sort=price%2Basc decodes to sort = price+asc. That %2B is a real plus sign kept as data, not a space (more on that next).
• note=caf%C3%A9 decodes to note = café. Two bytes, %C3%A9, are the UTF-8 spelling of é.

Notice the split personality of the ampersand in that one URL. The & between q=... and sort=... is raw, so it acts as a divider. The %26 inside the first value is encoded, so it’s plain text. Paste the whole string into a decoder and you’ll get exactly what’s above.

The plus sign quirk in form encoding

There are two slightly different traditions for a space, and the gap between them causes real confusion. Standard percent-encoding always uses %20, anywhere in the URL. But the older convention browsers use when they submit HTML forms encodes a space in the query string as a plus sign. So you’ll see both a%20b and a+b meaning the same thing, depending on how the URL was built.

This bites when a plus sign is actual data. In the form style, a real plus you want kept has to be written as %2B, because a bare + would be read as a space and lost. That’s exactly why the example above wrote price%2Basc: to keep the plus as a plus. Most modern tools handle the two styles for you, so you rarely choose by hand. The thing to hold onto is simple: a plus in a query string might be a space in disguise, and a literal plus has to be encoded to survive.

It’s reversible, not encryption

URL encoding looks technical, so people sometimes assume the percent codes hide something. They don’t. The mapping is a published standard, identical for everyone, with no key and no secret in it anywhere. Anyone who reads %26 knows it’s an ampersand, and any decoder turns the whole string back to plain text in one pass.

That makes URL encoding a transport format, the same family as Base64: a way to carry text safely through a channel with strict rules, not a way to keep it private. If a URL carries something sensitive, encoding it changes nothing about who can read it, because decoding is free and instant. Treat the percent codes as a different spelling of the same words, readable by anyone, and you’ll use them right. They make your link survive the trip. They were never a lock on the contents.