Base64 and URL encoding are both “make this safe to transmit as text” tools, so they’re easy to mix up. But they solve different problems. Here’s the distinction.
Same text, two encodings, side by side. We put
台北 101through both of our tools. Base64 returns5Y+w5YyXIDEwMQ==; the URL encoder returns%E5%8F%B0%E5%8C%97%20101. Both start from the identical 10 UTF-8 bytes, then diverge completely: Base64 re-expresses all bytes in a 64-character alphabet and pads to a multiple of four (hence the==), while percent-encoding leaves safe characters like1,0and1visible and escapes only the rest. That is why Base64 grows everything by a third and URL encoding grows only what it must.
Base64: binary → text
Base64 turns any binary data (an image, a file, raw bytes) into plain ASCII letters, digits, +, / and =. It grows the data by about 33%, and it is not encryption — anyone can decode it. Use it when a text-only channel needs to carry binary:
- Embedding an image in HTML/CSS as a
data:URI - Email attachments (MIME)
- Putting small binary blobs into JSON or a token
More on that in Is Base64 encryption? (spoiler: no).
URL encoding: safe text in a URL
URL encoding (a.k.a. percent-encoding) replaces characters that have special meaning or aren’t allowed in a URL with %XX codes — a space becomes %20, & becomes %26, and so on. Use it when putting text into:
- A query string (
?q=hello%20world) - A path segment
- Form submissions
See the URL encoding guide for details.
Key differences at a glance
- Purpose: Base64 = carry binary as text · URL encoding = make text safe in a URL.
- Output: Base64 = A–Z a–z 0–9 + / = · URL encoding = original text with
%XXescapes. - Size: Base64 ≈ +33% · URL encoding grows only the escaped characters.
The two schemes disagree most on non-ASCII input, and the gap is measurable. 台北 is six UTF-8 bytes. Base64 turns those six bytes into 5Y+w5YyX — eight characters. Percent-encoding turns the same six bytes into %E5%8F%B0%E5%8C%97 — eighteen characters, three per byte, because each byte becomes a literal % plus two hex digits. Base64 is far more compact; it is also unreadable in a URL bar, which is precisely why URLs use the other one.
They often combine
A Base64 string can contain +, / and =, which are unsafe in URLs — so if you put Base64 into a URL, you either URL-encode it or use Base64URL (a URL-safe variant using - and _).
Try both, locally
- Base64 encoder/decoder — binary/text ⇄ Base64.
- URL encoder/decoder — percent-encode text for URLs.
Rule of thumb: Base64 to carry binary as text; URL encoding to put text safely in a link.
A worked example
Take the text a b&c. Each encoder treats it completely differently:
Input: a b&c
URL-encoded: a%20b%26c
Base64-encoded: YSBiJmM=URL encoding leaves the letters alone and only escapes the space and the &, so the result is still readable. Base64 rewrites every byte into its own alphabet — four output characters for every three input bytes — so the output looks nothing like the input, but can now survive a channel that tolerates only a small set of safe characters. Different jobs, different output.
Padding is the part that looks arbitrary, and it stops looking arbitrary once you see four input lengths in a row. Base64 consumes three bytes and emits four characters; when the final group is short, = records how short it was. Every row below is our own Base64 encoder output.
| Input | Base64 | Padding |
|---|---|---|
a | YQ== | == |
ab | YWI= | = |
abc | YWJj | — |
abcd | YWJjZA== | == |
hello | aGVsbG8= | = |
台北 | 5Y+w5YyX | — |
🎉 | 8J+OiQ== | == |
Common misuses
- Using Base64 to “hide” data. It reverses in one step, so it protects nothing — treat it as an envelope, not a lock. See Is Base64 encryption?
- URL-encoding a whole URL. Encode the parts — a query value, a path segment — not the entire address, or you turn
https://intohttps%3A%2F%2Fand break the link. - Double-encoding. Encoding an already-encoded value gives
%2520(a%that was itself escaped). A space arriving as%2520instead of%20means something was encoded twice. - Forgetting Base64’s
+and/. Plain Base64 is not URL-safe; inside a URL, use Base64URL or URL-encode the string.
The most common misuse of Base64 is treating it as a way to hide something, and it is worth one concrete value. admin:password encodes to YWRtaW46cGFzc3dvcmQ=, which is exactly what HTTP Basic authentication puts in a header, and {"role":"admin"} encodes to eyJyb2xlIjoiYWRtaW4ifQ==. Both decode with no key at all. Percent-encoding is never mistaken for concealment because it stays readable; Base64 gets mistaken for it precisely because it does not. Neither is a security measure — one of them just looks more like one.
Where each one shows up
- Base64 appears wherever binary rides inside text:
data:URIs, email MIME parts, the segments of a JWT, and binary fields stuffed into JSON. - URL encoding appears wherever text rides inside a URL: query strings, form posts (
application/x-www-form-urlencoded), and path segments containing spaces or non-ASCII characters.
FAQ
Can I use Base64 instead of URL encoding?
No — they aren’t interchangeable. Base64 makes binary text-safe; URL encoding makes text URL-safe. Raw Base64 dropped into a URL can still break it because of +, / and =.
Why does my Base64 end with =?
That’s padding, added so the output length is a multiple of four. It’s normal, and some URL-safe variants omit it.
Does either one make data secure?
No. Encoding is about format, not secrecy — it’s fully reversible by anyone. For confidentiality you need encryption; for tamper-detection, a hash or signature.