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.
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:
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 isencodeURIComponent. - 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.

