Base64 Encoder / Decoder

The job Base64 is doing

Base64 (RFC 4648) converts arbitrary 8-bit bytes into a representation that uses only printable ASCII characters. It exists because many text protocols — SMTP, JSON, HTTP headers, XML attributes — cannot safely carry every byte. A null byte or a control character would terminate a string or break parsers. By limiting to 64 safe characters and padding to a 4-byte boundary, Base64 round-trips any binary payload through text-only channels.

The cost is size: every 3 bytes of input becomes 4 bytes of output, a 33% overhead. With padding, the worst case is up to 36%. This is why you shouldn't Base64-encode large files in JSON if you can avoid it — gzip + multipart upload is far more efficient.

Where Base64 shows up in real systems

**HTTP Basic Auth** — the username:password is Base64-encoded in the Authorization header. This is encoding, not encryption — anyone with the header can decode it. Use only over HTTPS.

**JWT** — the three dot-separated parts of a JWT (header, payload, signature) are URL-safe Base64. Decode the first two with any Base64 tool to see what's in a token.

**Email attachments (MIME)** — binary attachments are Base64-encoded with line breaks every 76 characters (RFC 2045). Embedding `data:` URIs in HTML uses the same encoding.

**Data URIs in CSS / HTML** — `data:image/png;base64,iVBORw...` lets you inline small images. Useful for icons, wasteful for anything over a few KB (your gzipped HTML grows by ~30% of the image size).

Standard vs URL-safe vs MIME

Standard Base64 (RFC 4648 §4) uses A-Z, a-z, 0-9, +, /, with = padding. URL-safe (§5) swaps + → - and / → _, and may omit padding. MIME Base64 (RFC 2045) is standard Base64 wrapped at 76-character line widths with CRLF.

A common bug: feeding a URL-safe-encoded string into a standard decoder. Most decoders are lenient (they accept either '-' or '+', either '_' or '/'), but strict ones — including some embedded systems and older Java APIs — will reject the wrong variant. JWT libraries always use URL-safe.

UTF-8 and the JavaScript pitfall

JavaScript's built-in `btoa()` and `atob()` only handle Latin-1 (single-byte) strings. If your input contains any character outside U+00FF — Cyrillic, Chinese, emoji — `btoa()` throws an error. To Base64-encode Unicode text in JavaScript, first encode to UTF-8 bytes (via `TextEncoder`), then Base64 those bytes.

Modern code: `btoa(String.fromCharCode(...new TextEncoder().encode(s)))`. On decode: `new TextDecoder().decode(Uint8Array.from(atob(s), c => c.charCodeAt(0)))`. This tool handles UTF-8 correctly.

What Base64 is NOT

Base64 is encoding, not encryption. Anyone can decode any Base64 string in milliseconds. It provides zero confidentiality. If you see secrets stored as Base64 in a config file or on the wire without TLS, that's a vulnerability — fix it.

Base64 is also not compression. The output is always larger than the input. If you need both safe-character encoding AND smaller size, gzip first, then Base64 the gzip output — but at that point you're inventing your own protocol, and a proper binary upload mechanism (multipart/form-data, gRPC) is almost always better.