How to Encode and Decode Base64

How the encoding works

Base64 reads the input three bytes at a time (24 bits) and writes four characters, each encoding 6 of those bits. The 64-character alphabet is A-Z, a-z, 0-9, plus + and / - with = added as padding when the final chunk is not a full three bytes. That 4-for-3 ratio is why encoded output is always about 33% longer than the input: a 300 KB file becomes about 400 KB of Base64.

Decoding is the exact reverse: four characters back to three bytes. Because it is a lossless bijection over byte sequences, there is nothing to lose - and nothing to hide. The output of encoding "hello" (aGVsbG8=) is readable by everyone, everywhere, at all times.

Input:   "hello"
Output:  aGVsbG8=
Length:  5 bytes -> 8 characters (4-for-3, padded)

Where Base64 actually appears

You meet it constantly and rarely name it:

• Auth headers: "Basic" authentication sends Base64 of user:password. It is obfuscation for transport, not protection - treat the header as plaintext.
• Data URIs: <img src="data:image/png;base64,...."> embeds an image directly in HTML or CSS, avoiding a separate request. Fine for small assets; a 2 MB logo as a data URI is a page-speed problem.
• Email and MIME: attachments in email are Base64 text inside an otherwise text protocol - the reason a 1 MB PDF attachment takes about 1.35 MB on the wire.
• JSON and logs: binary blobs (thumbnails, avatars) embedded as Base64 strings inside JSON payloads, where the same 33% tax applies.
• Certs and keys: PEM files are Base64 of DER data, wrapped in BEGIN/END lines. The wrapping is for humans; the Base64 is for text transport.

The failure modes

Decoding problems are a short list, and each has a tell:

• Wrong alphabet: a string containing + and / inside a URL needs URL-safe Base64 (- and _ instead), or the + became a space in transit. Check which alphabet the producer used.
• Broken length: valid standard Base64 has a length that is a multiple of 4 (with = padding). A length of 4n+1 is impossible - the string was truncated or mangled. Lengths of 4n+2 or 4n+3 mean missing padding, which most decoders will fix or reject depending on strictness.
• Double encoding: Base64 of Base64. Decode once and the result still looks like Base64 - decode again. This happens when a pipeline encodes, stores, then "encodes for safety" a second time.
• Smart-quote and whitespace damage from copy-paste: newlines inside a pasted string, or quotes converted by a chat client, will fail strict decoders.

The one rule that matters

Base64 is transport, not security. If a system is using Base64 where it should be using encryption - a password in an auth header, a token in a URL, "encrypted" config that is really just Base64 - the protection is an illusion. The correct mental model: Base64 makes binary legible to text systems, and it is as confidential as writing the same bytes in plain sight. For anything that needs to be secret, encryption (or at minimum a secret you control) is the job; Base64 just carries it.

Frequently asked questions