Base64 encode / decode

Base64 takes input three bytes at a time, splits the 24 bits into four 6-bit groups, and maps each group to one of 64 printable characters (A-Z a-z 0-9 + /). The encoded form is always a multiple of 4 chars; = pads the last block when the input isn't a multiple of 3.

The trade-off is size: encoded data is ~33% bigger. The upside is that it survives any channel that strips or rewrites non-printable bytes — which historically was most of email and many APIs.

There are two RFC 4648 alphabets you'll encounter:

• Standard (§4) uses + and / plus = padding. This is what MIME / email, PEM-encoded keys, and most legacy APIs emit.
• URL-safe (§5) swaps + → - and / → _, then strips the = padding. This lets the encoded string sit in a URL path, query string, filename or JWT segment without further escaping. JWT, OAuth tokens and many file IDs use this variant.

The decoder accepts either — we normalise the alphabet and re-pad before calling atob.

Multi-byte UTF-8 characters — emoji, accented Latin, CJK, Arabic, Hebrew — must be converted to bytes first, then Base64-encoded. The browser's TextEncoder handles this:

const bytes = new TextEncoder().encode("café 🚀");
btoa(String.fromCharCode(...bytes));

This tool wraps that wrapper for you, so any Unicode input round-trips losslessly.

• Data URIs — data:image/png;base64,iVBOR… inlines an image into HTML/CSS without a separate request.
• HTTP Basic Auth — the Authorization: Basic header is base64(username:password).
• JWT — header, payload and signature are URL-safe Base64-encoded JSON / bytes.
• API keys / nonces — random bytes from a CSPRNG, encoded for safe transport.
• Email attachments — MIME wraps binary attachments in 76-column Base64.

The most common misuse is treating Base64 as "obfuscation". A secret left in client-side JS as const apiKey = atob("…") is exactly as exposed as the unencoded string. Use real secret-handling primitives (server-side env vars, OAuth, KMS) for anything that needs to stay private.