All posts

Why %20 keeps showing up in your URLs — URL encoding explained

What percent-encoding is, when you need it, the difference between encoding a whole URL and a single value, and how to parse a query string.

8 June 20263 min readBy Primova
urldevencoding

If you've ever seen %20 in a link, or a URL that ends in a soup of %3D and %26, you've met URL encoding. It looks like corruption but it's the opposite — it's how a URL stays unambiguous. Here's what's actually happening, when you need to do it yourself, and the one mistake that bites everyone.

The problem it solves

A URL has a grammar. Certain characters are structural? starts the query string, & separates parameters, = joins a key to its value, / separates path segments. So what happens when one of your actual values contains those characters?

Say you're searching for "rock & roll" and putting it in a ?q= parameter. The & in your value would look like the start of a new parameter, and the URL silently breaks:

One ampersand, two very different URLsRAW — the & looks like a new parameter?q=rock & roll&page=2← server sees an extra paramENCODED — the & is safely part of the value?q=rock%20%26%20roll&page=2

Percent-encoding fixes this by replacing any character that could be misread with a % followed by its byte value in hex. A space becomes %20, & becomes %26, = becomes %3D. Now the value can't be confused with the URL's structure — the browser knows %26 is a literal ampersand inside your data, not a separator.

The distinction that trips everyone up

There are two different jobs here, and using the wrong one is the single most common URL-encoding bug:

  • Encoding a single value (one query parameter, one path piece). Here you want &, =, ?, and / encoded, because they're data, not structure. In JavaScript this is encodeURIComponent.
  • Encoding a whole URL. Here you want those same characters left alone, because they're doing their structural job. This is the gentler encodeURI.

The classic mistake is running a whole URL through the aggressive encoder, which mangles the :// and the ? into %3A%2F%2F and produces something unusable.

Rule of thumb: encode each value before you assemble it into the URL — never the finished URL afterwards. Build the pieces safe, then glue them together.

Reading a query string

The reverse situation: someone hands you a long URL and you need to see what's in the ?... part — the tracking parameters, the filters, the token. Eyeballing ?utm_source=x&ref=y&ids=1%2C2%2C3 is tedious, and the encoding hides the real values. What you want is that query string broken into a clean key/value table with everything decoded, so %2C turns back into the comma it always was.

Doing it without guessing

Primova's URL Encoder / Decoder does all three jobs: encode a value safely, decode a percent-encoded string back to readable text, and parse a full query string into a table of decoded key/value pairs.

It runs in your browser, so any URL you paste — including ones with auth tokens or personal data in the parameters — stays on your machine. (Putting sensitive values in a URL is its own bad idea, but if you're debugging one that already exists, you definitely don't want to hand it to a third-party server to decode.) Next time a link is full of %-codes and you want to know what it's really pointing at, drop it into the URL Encoder / Decoder.