Base64

Base64 Lessons: How Encoding Turns Data Into Safe Text

Encoding lesson · 8-minute read

You will meet Base64 the moment you try to put an image, a file, or any raw binary into JSON — because JSON only holds text. Base64 is the standard way to carry binary safely through text-only channels. This lesson covers what it does, how it works, and the mistakes people make with it.

The problem Base64 solves

Computers store images, fonts and encrypted blobs as binary — arbitrary bytes from 0 to 255. Many systems were built to carry only text: email bodies, URLs, and JSON string values among them. Drop raw bytes into those channels and something breaks — a byte that happens to mean "end of line" or "end of string" corrupts the message.

Base64 fixes this by re-expressing any bytes using only a small set of characters that every text system treats as ordinary. The data survives the trip intact, then gets decoded back to the original bytes at the other end.

How the encoding works

The name is the recipe: Base64 uses 64 characters — A–Z, a–z, 0–9, plus + and /. Sixty-four options is exactly 6 bits of information per character.

The trick is regrouping bits. Binary data is 8 bits per byte; Base64 reslices it into 6-bit chunks:

Take 3 bytes of input — that is 24 bits.
Split those 24 bits into four 6-bit groups.
Map each 6-bit group (a value 0–63) to one character from the alphabet.

So every 3 bytes in become 4 characters out. Walk through the word "Hi":

Text:    H        i
ASCII:   72       105
Bits:    01001000 01101001
Regroup: 010010 000110 1001(00)
Values:  18     6      36
Base64:  S      G      k     =
Result:  "Hi"  →  "SGk="

What the "=" padding means

Base64 works in blocks of 3 input bytes. When the input length is not a multiple of 3, the final block is short, and the output is padded with = to keep it a multiple of 4 characters:

3 bytes left over → no padding ("abc" → "YWJj")
2 bytes left over → one = ("ab" → "YWI=")
1 byte left over → two = ("a" → "YQ==")

The = is not data — it is alignment, telling the decoder how many bytes the last block really held.

The size cost

Because 3 bytes become 4 characters, Base64 output is about 33% larger than the input. That is the price of text-safety: a 90 KB image becomes roughly 120 KB of Base64. Fine for a small inline icon in JSON; wasteful for large files, which are better sent as raw binary over a separate channel.

The most important lesson: Base64 is not encryption

This trips up beginners constantly. Base64 is encoding, not encryption. There is no key and no secret — anyone can decode it instantly. It scrambles nothing and protects nothing.

If you Base64 a password to "hide" it, you have hidden nothing. It is reversible by anyone in one step.

Use Base64 for transport (getting binary safely through a text channel), never for secrecy. For secrecy you need real encryption.

Base64 and JSON

This is why the two topics live together. JSON strings hold text only, so to embed a small image or binary blob you Base64-encode it and store the result as a normal string value:

{
  "filename": "logo.png",
  "type": "image/png",
  "data": "iVBORw0KGgoAAAANSUhEUgAA..."
}

The data field is plain Base64 text — valid JSON, safe to send anywhere. Just remember the 33% size overhead before inlining anything large.

Working with JSON that carries Base64 fields? Format and validate the whole document in your browser — nothing uploaded.

Open the JSON Formatter

A dedicated Base64 encoder/decoder is on the way to the LK Forge developer tools. In the meantime, the JSON formatting rules cover how to embed encoded strings correctly, and what JSON is explains the format that carries them.