All articles

Base64: why encoding is needed and how it works

Base64 is a way to represent arbitrary binary data as text made up only of letters, digits, and the characters +, /, and =. It doesn't compress or encrypt anything — the result is about a third larger than the input, and anyone who knows the algorithm can read the original content.

How the encoding works

Input bytes are grouped in threes (24 bits) and split into four six-bit blocks. Each block maps to one character from the Base64 alphabet (A–Z, a–z, 0–9, +, /). If the input length isn't a multiple of three bytes, a padding character = is appended at the end.

Why it's needed

Many protocols and formats — email (MIME), URLs, JSON, XML — are built for text and can't reliably carry "raw" bytes: null bytes, control characters, or byte sequences that clash with the format's own syntax. Base64 works around this by turning any binary data into safe text.

Common use cases

  • Email attachments via MIME.
  • Sending images or small files inside a JSON API.
  • Storing binary data in text-only database fields or config files.
  • Encoding the header and payload parts of a JWT.

What Base64 is NOT

It's not encryption and not hashing. Anyone can decode a Base64 string back to the original data without a key or password — it's purely a representation format, not a security measure.

Standard vs. URL-safe alphabet

The classic Base64 alphabet uses the characters + and /, which have special meaning in URLs and file names. For those cases there's a Base64URL variant, where + is replaced with - and / with _. If you drop a standard Base64 result into a URL without additional percent-encoding, the + and / characters can corrupt the address or clash with path separators.

A common mistake: truncated or stripped padding

The = character at the end of a string isn't junk — it's part of the encoding, showing how many bytes are missing from the final block. If you copy a Base64 string incompletely or strip the padding manually, the decoder will return an error or a garbled result. Some systems (JWT, for instance) deliberately drop the =, in which case the length needs to be restored before decoding.

Try the tool