How Base64 Encoding Actually Works

Base64 shows up constantly in web development, email attachments, and API payloads — anywhere binary data needs to travel safely through a system designed for plain text.

What it actually does

Base64 takes input data (any bytes, including plain text) and re-encodes it using only 64 characters: A-Z, a-z, 0-9, plus two more symbols (typically + and /). Because those 64 characters are universally safe to transmit through text-based systems (email, JSON, URLs with minor tweaks), Base64 sidesteps compatibility issues that raw binary data would otherwise cause.

A concrete example

The plain text "Hello, world!" encodes to "SGVsbG8sIHdvcmxkIQ==". Notice the encoded version is noticeably longer than the original — that's expected. Base64 groups input bytes into sets of 3, then re-expresses each group as 4 output characters, which means encoded output is always roughly 4/3 the size of the original input (about 33% larger).

Why the trailing "==" sometimes appears

The 3-bytes-in, 4-characters-out grouping only works cleanly when input length is a multiple of 3 bytes. When it isn't, Base64 pads the output with one or two "=" characters to complete the final group — which is why some encoded strings end in "=" or "==" and others don't, depending purely on the original input's length modulo 3.

Why it is not encryption

Base64 is fully and trivially reversible by anyone — decoding requires no secret key, no password, nothing beyond knowing it's Base64-encoded data in the first place. Anyone who suspects a string is Base64 can decode it in seconds using any of thousands of free tools. If you see credentials or sensitive data "protected" by Base64 encoding in an API or config file, it should be treated as equivalent to plain, unprotected text — the encoding provides zero confidentiality.

Where Base64 is genuinely useful

• Embedding small images directly inside CSS or HTML ("data:image/png;base64,...") without a separate file request
• Safely including binary attachments inside text-based email formats (MIME)
• Passing binary tokens or keys through systems (like URL query parameters or JSON fields) that only reliably support plain text characters

Common mistakes to avoid

• Assuming Base64-encoded data is protected or hidden — it is neither, and should never be relied on for confidentiality
• Forgetting the ~33% size increase when estimating payload sizes for encoded binary data (like embedded images)
• Mixing up Base64 with URL encoding — they solve different problems (binary-to-text safety vs. special-character safety in URLs) and are often used together, not interchangeably

Try it yourself with the Base64 encoder/decoder, and see the related URL encoder/decoder for the other common text-safety transformation.