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

You see a web address with %20 scattered through it, or a search link where every space became a percent sign and two digits, and it looks like the URL broke. It did not. That is URL encoding doing its job, and once you know the rule behind it, the cryptic-looking address reads as plainly as the words you typed. The reason this matters is that a single unencoded character can quietly send a link to the wrong place.

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 hex value of their byte. That is why a space becomes %20 and an ampersand inside a value becomes %26. It is fully reversible and not encryption, so anyone can decode it.

Why URLs only allow a limited set of characters

A URL was designed to be safe to print, type, and pass between very different systems, so it can only use a small set of characters reliably. The safe set is letters A to Z and a to z, the digits 0 to 9, and a handful of marks like the hyphen, period, underscore, and tilde. Everything else risks being misread along the way.

The problem is that the text you want to put 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 URL at all, and if it slips through raw, some systems trim it, some break the link, and some split the address in two. Rather than hope every system handles odd characters the same way, URL encoding converts the risky ones into a form that every system already understands.

How percent-encoding turns a space into %20

Percent-encoding follows one rule. Take the unsafe character, look up the hex value of its byte, and write a percent sign followed by those two hex digits. The percent sign is the flag that says “an encoded character follows,” and the two digits are the value. A space is byte 32, which is 20 in hexadecimal, so a space becomes %20. An ampersand is %26. A hash is %23.

Because the rule is mechanical and fixed, it runs in both directions. Encoding walks through the text and swaps each unsafe character for its percent code. Decoding spots each percent sign, reads the next two digits, and puts the original character back. There is no guessing and no key involved, which is why a URL encoder and decoder at dev.hivly.net can convert a string either way in one step and hand you an exact match of the original.

Reserved characters versus characters that just need escaping

Here is the part that trips people up: some characters are not banned, they are reserved, meaning 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 characters are allowed precisely because the 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 these reserved characters when they appear inside a value and you want them treated as ordinary text rather than as 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 URL as a form with labelled slots, and the reserved characters as the labels. The structure of a query string is ?name=value&name=value, where the question mark, equals signs, and ampersands hold the shape. Those delimiters must stay raw, because they are what tells the receiving system where one piece ends and the next begins. Encode them and you erase the structure.

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

The plus sign quirk in form encoding

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

This matters when a plus sign is actual data. In the form-encoding style, a real plus that you want kept must be written as %2B, because a bare plus would be read as a space and lost. Most modern tools and libraries handle the two styles correctly on their own, so you rarely have to choose by hand. The thing to remember is simple: a plus in a query string might be a space in disguise, and a literal plus has to be encoded to survive.

URL encoding is reversible, not encryption

URL encoding looks technical, so people sometimes assume the percent codes hide something. They do not. The mapping is a published standard, identical for everyone, with no key and no secret anywhere in it. Anyone who reads %26 knows it is an ampersand, and any decoder turns the whole string back into 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 will use them correctly. They make your link survive the trip; they were never a lock on the contents.