Web & APIs · 4 min read
Base64 Explained: Encoding vs Encryption
Base64 shows up everywhere — data URIs, JWTs, email attachments, API payloads — yet it is widely misunderstood. The single most important thing to know is that Base64 is encoding, not encryption. It hides nothing.
This guide explains what Base64 is for, why it makes data larger, and when reaching for it is the right call.
Try it yourself with the related tool.
Encode or decode Base64 →Advertisement
Why Base64 exists
Many systems were built to carry text, not arbitrary bytes. Email bodies, JSON string fields, and URLs can be corrupted by raw binary data or control characters. Base64 solves this by representing any bytes using just 64 safe ASCII characters (A–Z, a–z, 0–9, plus two symbols), so binary data can travel safely through text-only channels.
Why it grows by ~33%
Base64 encodes every 3 bytes of input as 4 output characters. That 4:3 ratio means encoded data is roughly a third larger than the original. It is the price you pay for text safety, which is why you should only inline small assets (like tiny icons) as Base64 data URIs.
Encoding is not encryption
Because the alphabet is public and the transformation is reversible, anyone can decode Base64 instantly. Using it to "hide" a password or token provides zero security. If you need confidentiality, use real encryption such as AES. Base64 is about safe transport, not secrecy.
Standard vs URL-safe
Standard Base64 uses + and /, which have special meaning in URLs. URL-safe Base64 swaps them for - and _ and often drops the = padding, so the result can go straight into a query string or a JWT without extra escaping.