Two encodings, two different jobs
Both Base64 and URL encoding replace “unsafe” characters with safe ones. That surface similarity is why they get mixed up — and why people sometimes apply both when one would do, or apply the wrong one entirely.
The short version:
- Base64 makes binary data survive a text-only channel.
- Percent-encoding makes text survive a URL.
What each one actually does
Base64 rewrites bytes using a 64-character alphabet (A–Z a–z 0–9 + /, plus = padding). Every 3 bytes become 4 characters, so output grows by about 33%.
Man → TWFu
Hello → SGVsbG8=
Percent-encoding replaces characters that are unsafe in a URL with % plus two hex digits representing the UTF-8 byte.
a b → a%20b
书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86
a&b → a%26b
The key difference
| Base64 | Percent-encoding | |
|---|---|---|
| Purpose | Move binary through text channels | Keep text safe inside a URL |
| Alphabet | 64 fixed characters | Any byte, as %XX |
| Size change | +33% | Varies wildly |
| Reversible by anyone | Yes | Yes |
| Provides security | No | No |
| Typical home | JSON fields, data URIs, MIME, JWT | Query strings, path segments |
When to use Base64
- Embedding a small image in CSS or HTML as a data URI
- Sending a file or signature inside a JSON payload
- Email attachments via MIME
- Building an
Authorization: Basicheader - Any JWT header or payload segment
Reach for the Base64 encoder/decoder when you need to convert in either direction without installing anything.
When to use percent-encoding
- A query parameter value that contains
&,=,#,?, a space, or non-ASCII text - A filename or slug placed in a path
- Passing a URL as a parameter of another URL (this is where double-encoding bugs come from)
The URL encoder/decoder uses encodeURIComponent, which is the behaviour you want for parameter values.
The three mistakes that cause most bugs
1. Using Base64 where percent-encoding is needed. A Base64 string contains + and /. Put it directly into a query string unencoded and the + will be read as a space by many parsers. Fix: use the URL-safe alphabet (- and _), or percent-encode the result.
2. Double encoding. Encoding an already-encoded string produces something that still looks valid but means nothing. The tell-tale sign is %25 at the start of a percent-encoded payload (%25 is %).
3. Treating either as security. Both are fully reversible with no key. If you need confidentiality, encrypt then encode.
Which one does my case need?
Ask one question: is the destination a URL or a text container?
- A URL (query string, path) → percent-encoding
- A text container (JSON, HTML attribute, email body, CSS) → Base64 if the payload is binary; plain text otherwise
Try both side by side
- Base64 encoder / decoder — text and binary, UTF-8 safe, runs offline
- URL encoder / decoder — query parameters and paths
- Base64 encoding explained — the longer guide
- URL encoding explained — percent-encoding in depth
FAQ
Can I Base64 something and then put it in a URL?
Yes, but percent-encode the Base64 first (or use Base64URL). Otherwise +, / and = will cause trouble.
Is percent-encoding ever longer than Base64? Often yes — non-ASCII text expands to 9 characters per CJK character in UTF-8 encoding, far more than Base64’s 33% overhead.
Does either one compress data? Neither. Compress first (gzip/Brotli), then encode.
Which one should I use for a password? Neither. Use a password manager and real encryption — encoding is not protection.