URL encoding: when you need it and how to get it right
By the Converterzilla Team
We build privacy-first PDF and image tools that run entirely in your browser. Our team has shipped JavaScript file-processing apps used by thousands every day, and we write here about the libraries, trade-offs and patterns we use.
URLs can only contain a limited set of characters safely — letters, digits, and a handful of punctuation marks. Anything else (spaces, accented characters, &, ?, non-Latin scripts) has to be percent-encoded: replaced with a % followed by the character's hex byte value, so "café & bikes" becomes caf%C3%A9%20%26%20bikes.
Reserved vs. unreserved characters
The URL spec splits characters into two groups. Unreserved characters (letters, digits, - _ . ~) never need encoding — they're always safe. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning as delimiters within a URL, so if you need one of them to appear literally as data rather than as a delimiter, it must be percent-encoded to avoid being misread as part of the URL's structure.
The space character has two valid encodings, and that's the trap
This is where most bugs happen. A literal space should be %20 — that's correct everywhere. But inside a URL's query string, + is also commonly interpreted as a space, for historical reasons tied to HTML form submission (application/x-www-form-urlencoded). The two encodings are not interchangeable outside that context: encode a space as + in a URL path segment and it will be read as a literal plus sign, not a space. Know which part of the URL you're encoding for.
Encode components, not whole URLs
A very common mistake is running an entire URL through a URL encoder, which dutifully encodes the ://, turning https://example.com/search?q=hi into a broken string. The right approach is to encode each dynamic value going into the URL — the query parameter, the path segment — and leave the URL's own structural characters (://, ?, &, =) untouched.
Double-encoding is a real bug, not just untidy
If a value is already percent-encoded and gets encoded again, %20 becomes %2520 (the % itself gets encoded to %25). This is a common source of "the link works when I paste it manually but breaks when the app generates it" bugs — usually because encoding happens twice somewhere in a redirect chain or a copy-pasted URL that was already encoded.
Our URL encoder and URL decoder apply standard percent-encoding rules entirely in your browser — handy for checking exactly what a query parameter or redirect URL will decode to before you ship it.