Base64 Encoding: How It Works & When to Use It

Index

0-25

26-51

52-61

Padding

Char

A-Z

a-z

0-9

Base64 Encoding: How It Works & When to Use It

Updated 2026.08.01~3 min read

Base64 packs 3 bytes into 4 ASCII chars (A-Z, a-z, 0-9, +, /) — +33% size, universally safe through text channels. Padding "=" marks the remainder. NOT encryption — trivially reversible. Uses: data URIs, email attachments, API tokens. URL-safe variant swaps +/ to −_.

Key Takeaways

Mechanism: 3 bytes (24 bits) → 4 chars (6 bits each) from a 64-char alphabet

Cost: +33% size (4/3), plus up to 2 padding "=" chars

Not encryption: Base64 is encoding — anyone decodes it instantly; secrets stay secret only via real crypto

URL-safe: replace + → −, / → _, drop padding for URLs/filenames (JWT uses this)

Core answer: Base64 encodes binary data as 64 safe ASCII characters (A–Z, a–z, 0–9, +, /) at a 33% size cost: every 3 bytes become 4 characters, padded with =. "Hi" → "SGk=". It's encoding, NOT encryption — anyone can decode it instantly. Uses: data URIs, email attachments (MIME), JWT payloads, basic auth headers. URL-safe Base64 swaps +/ for −_ and drops padding.

How the encoding works

3 bytes = 24 bits = 4 groups of 6 bits; each 6-bit group indexes the 64-char alphabet. "Man" (77, 97, 110) → 010011 010110 000101 101110 → T W F u → "TWFu". Leftover bytes pad with =: 2 bytes → 3 chars + one =; 1 byte → 2 chars + ==.

Input	Base64
"M"	TQ==
"Ma"	TWE=
"Man"	TWFu
"Hello, 世界"	SGVsbG8sIOS4lueVjA==

Where you meet it daily

Data URIs: data:image/png;base64,iVBOR... embeds small images in CSS/HTML (saves a request, costs 33% bytes + no caching).
JWT: header.payload.signature are each base64url — paste any JWT into a decoder to read claims (the signature only proves integrity, payload is NOT secret!).
HTTP Basic auth: Authorization: Basic dXNlcjpwYXNz = "user:pass" — plaintext-equivalent; only safe over HTTPS.
Email (MIME): attachments ride as base64 because SMTP was built for 7-bit text.
Certificates: PEM files are base64 between BEGIN/END lines.

Worked examples

Example 1 — Debugging a JWT. eyJhbGciOi... decodes to {"alg":"HS256","typ":"JWT"}; the middle segment reveals user/role/exp — if sensitive data sits in a JWT payload, that's a leak by design.

Example 2 — Quick CLI. Encode: echo -n "hello" | base64 → aGVsbG8=; decode: echo "aGVsbG8=" | base64 -d. macOS/Linux both ship it.

Example 3 — Size math. A 300 KB PDF inline in JSON becomes 400 KB of base64 plus JSON escaping — for APIs, prefer binary endpoints or pre-signed upload URLs instead.

Common mistakes and myths

"It's encrypted" — base64 is a public encoding with no key; never use it to "protect" secrets.
URL breakage — + and / break query strings and paths; use base64url (− and _, no padding) in URLs and JWTs.
Double-encoding — storing base64 of base64 happens in layered systems; if decoded output looks like base64, check your pipeline.
Line-wrap variants — MIME wraps at 76 chars; some parsers choke on wrapped vs unwrapped; strip whitespace before decoding.
Binary-in-JSON without thinking — 33% bloat plus CPU on both ends; fine for avatars, wrong for videos.

Frequently Asked Questions

How does Base64 encoding work?

Take 3 bytes = 24 bits, split into four 6-bit groups, map each to a character in the 64-char alphabet (A-Z, a-z, 0-9, +, /). "Hi!" = 0x48 0x69 0x21 → bits → groups of 6 → "SGkh". Leftover 1-2 bytes get padded with "=" to complete the quartet ("SGk=" for "Hi"). Every 3 bytes become exactly 4 printable ASCII characters — safe to pass through systems designed for text.

Why does Base64 grow data by 33%?

6 useful bits are stored in each 8-bit character — efficiency 6/8 = 75%, size 4/3 = 133%. 3 KB image → 4 KB Base64. Plus in JSON/HTML the string may need further escaping. That is the tax for text-channel safety. Rule: fine for small payloads (icons, tokens, short files); wrong for megabyte assets — serve those as binary with proper URLs.

Where is Base64 actually used?

(1) Data URIs: small images inline in CSS/HTML (data:image/png;base64,...) — saves an HTTP request under ~2-4 KB; (2) email attachments (MIME); (3) basic auth headers (Authorization: Basic base64(user:pass) — over TLS only!); (4) tokens & certs (JWT segments, PEM files); (5) binary data in JSON/XML; (6) webhooks signatures. The common thread: binary safely crossing text-only pipes.

What is URL-safe Base64?

Standard Base64 uses + and / — both meaningful (and dangerous) in URLs. The URL-safe variant (RFC 4648) swaps + → − and / → _, and typically omits = padding: "SGkh" stays, but binary producing "+/" becomes "-_". JWTs, OAuth tokens and URL-embedded data use this. Filenames have the same problem on some filesystems. When interop fails with weird characters, mismatched variants are suspect #1.

Is Base64 a security measure?

No. Encoding ≠ encryption: there is no key, and every developer tool decodes it in one click. base64(user:password) protects against shoulder-surfing for about 3 seconds. Real protection layers: TLS in transit, hashing (bcrypt/argon2) for stored passwords, encryption (AES with a secret key) for stored data. "It looks scrambled" is not a security property — treat Base64 payloads as plaintext.

What mistakes happen with Base64?

(1) Assuming it encrypts (see above — the classic audit finding); (2) inlining huge images as data URIs (+33% size, uncacheable, blocks rendering); (3) standard vs URL-safe variant mismatches causing signature failures; (4) double-encoding (Base64 of Base64) when layers each encode; (5) padding errors — some strict decoders reject missing =, others reject present ones; (6) newlines: MIME wraps at 76 chars — strip whitespace before decoding; (7) using Base64 to "compress" (it inflates; gzip first, then Base64 if you must).