Guide
What is Base64 encoding (and when to use it)
A clear guide to how Base64 turns binary data into safe ASCII text, why it grows your data by a third, and where to use it — encoder built in.
Base64 is a way to represent arbitrary binary data using only 64 printable ASCII characters. It exists because many channels — URLs, email headers, JSON strings, XML — were designed for text, not raw bytes. Base64 lets you push binary through those channels without corruption. Paste any text into the encoder above to see the transformation.
How it maps 3 bytes to 4 characters
The core trick is regrouping bits. Base64 takes the input 3 bytes (24 bits) at a time and
splits those 24 bits into four groups of 6 bits. Each 6-bit group is a number from 0 to 63,
which indexes into the alphabet A–Z, a–z, 0–9, +, and /.
Take the three letters Man:
M a n
01001101 01100001 01101110 ← 24 bits
010011 010110 000101 101110 ← regrouped into four 6-bit values
19 22 5 46
T W F u ← looked up in the Base64 alphabet
So Man encodes to TWFu. Three input bytes always become four output characters.
The ~33% size increase
Because every 3 bytes become 4 characters, the output is always larger than the input by about one third. A 9 KB image becomes roughly 12 KB once Base64-encoded. This is the trade-off: you gain text safety but spend bandwidth and storage. For large assets, keep the file binary and reference it by URL instead of inlining it.
Padding with =
The 3-byte grouping is tidy only when the input length is a multiple of 3. When it is not, Base64 pads the final group:
- 1 leftover byte → 2 encoded characters +
== - 2 leftover bytes → 3 encoded characters +
=
M → TQ==
Ma → TWE=
Man → TWFu
The = characters are not data — they tell the decoder how many real bytes the last group holds.
It is encoding, not encryption
This is the point that trips people up most. Base64 provides no security whatsoever. The
alphabet and the algorithm are public, so anyone can decode the output instantly — try it with the
decoder linked above. If you see a Base64 string in a config file, a token, or a request, assume
it is fully readable. To actually protect data you need encryption (AES, for example) or, for
fixed-length fingerprints, a hash like SHA-256.
The URL-safe variant
Standard Base64 uses + and /, both of which are reserved characters in URLs and illegal in
many filenames. The URL-safe variant swaps them:
| Standard | URL-safe |
|---|---|
+ |
- |
/ |
_ |
Padding = is often dropped too, since = also has meaning in query strings. This variant is
what you see in JWTs and many API tokens.
Where Base64 is actually used
- Data URIs — embedding a small image or font directly in HTML/CSS:
data:image/png;base64,iVBORw0KGgo...so the browser makes no extra request. - Email attachments — MIME encodes binary attachments as Base64 so they survive text-only mail transport.
- Binary inside JSON or XML — JSON has no native binary type, so byte blobs (a small file, a cryptographic key) are carried as Base64 strings.
- Tokens and identifiers — JWTs and many opaque tokens use URL-safe Base64 so they travel cleanly in headers and links.
A good rule: reach for Base64 when you must move bytes through a text-only pipe, accept the ~33% overhead, and never mistake it for a way to hide anything.