Base64 Encoder / Decoder

Base64 works by regrouping data 3 bytes (24 bits) at a time into four 6-bit chunks, then mapping each 6-bit chunk to one character from a fixed 64-character alphabet — A-Z, a-z, 0-9, plus two more symbols (+ and / in standard Base64). Six bits can represent exactly 64 distinct values, which is where both the name and the alphabet size come from. Since 24 divides evenly by both 8 (a byte) and 6 (a Base64 character), 3 input bytes always map cleanly to exactly 4 output characters.

When the input length isn't a multiple of 3, the last group is padded with = characters so the output always has a length that's a multiple of 4 — one = if there's one leftover byte's worth of data missing a full group, two = if there are two. That's why you'll see Base64 strings ending in one or two equals signs (or none at all, when the input happened to divide evenly), and it's also why decoders that reject non-padded input will fail on otherwise-valid Base64 from a source that omits padding.

The two extra characters in the standard alphabet, + and /, are both reserved characters in a URL — a + can mean a space in query strings, and a / is a path separator. Putting standard Base64 straight into a URL without further percent-encoding risks corrupting it. RFC 4648 defines a URL-and-filename-safe variant (often called Base64URL) that swaps + for - and / for _, and conventionally drops the = padding entirely since it's derivable from the string length.

This is exactly the variant JWTs use for their three segments, and it's why a JWT-shaped string looks like ordinary Base64 but won't always decode correctly with a strict standard-alphabet decoder — the - and _ characters need translating back to + and / (and padding needs restoring) before a standard Base64 decoder can read it.

The distinction matters because the two get conflated constantly: encryption transforms data using a secret key such that reversing it is computationally infeasible without that key. Base64 has no key at all — the mapping from bytes to characters and back is completely public and identical for everyone, defined entirely by the RFC. Anyone can decode a Base64 string with a single line of code in virtually any language; there is no secret to protect.

Base64 shows up in security-adjacent contexts (JWT payloads, Basic Authentication headers) purely because those formats need binary or structured data to travel safely through text-only channels — not because Base64 offers any confidentiality. If a payload needs to stay secret, it must be encrypted before being Base64-encoded, not instead of it.

Base64 was popularized by MIME (Multipurpose Internet Mail Extensions) in the early 1990s specifically to let binary attachments — images, documents — travel through email systems that were only guaranteed to handle 7-bit ASCII text reliably. That same need for "binary data inside a text-only channel" is why Base64 still shows up everywhere decades later: a data: URI embeds an image directly inside HTML or CSS as text (data:image/png;base64,...), avoiding a separate HTTP request for small images.

HTTP Basic Authentication sends credentials as Base64(username:password) in an Authorization header — worth knowing precisely because it means Basic Auth credentials are trivially readable by anyone who can see the request, which is exactly why Basic Auth is only considered acceptable over HTTPS, where the encryption is provided by TLS, not by the Base64 encoding itself.

The ~33% size increase isn't a rounding error to ignore at scale: a 3 MB file becomes roughly a 4 MB Base64 string, and that overhead compounds if the encoded string is itself embedded inside another format like JSON, which adds its own quoting and escaping on top. For genuinely large payloads — file uploads, large images — sending raw binary (multipart form data, or a direct binary body) is almost always more efficient than embedding Base64 inside a JSON API request, precisely because it skips this overhead entirely.

Base64 earns its overhead specifically when a format has no other way to carry binary data — a JSON field, a URL, an email body, a data: URI meant to avoid a second HTTP round-trip for a small icon. For anything larger, or any format that natively supports binary bodies, encoding it as Base64 first is usually solving a problem that doesn't need solving.

Base64 and hex (hexadecimal) are both ways to represent binary data as printable text, but they make different trade-offs. Base64 uses a 64-character alphabet (A–Z, a–z, 0–9, +, /) to encode 6 bits per character, producing roughly 33% size overhead — three bytes of binary become four characters. Hex uses 16 characters (0–9, a–f) to encode 4 bits per character, so each byte becomes two characters, a full 100% size overhead. A 16-byte value that is 32 characters in Base64 is 64 characters in hex.

Hex wins on readability: it maps directly to byte boundaries, making it easy to spot individual bytes, and it's the standard representation for cryptographic hashes, MAC addresses, color values, and memory dumps. Base64 wins on efficiency and is the de facto standard for embedding binary data in text-only contexts — email attachments (MIME), data URIs, and JSON payloads. Choose hex when you need to read or compare raw bytes; choose Base64 when you need to move binary data through a text channel and size matters.