Base64 Encoding Explained

Base64 is the world's most ubiquitous binary-to-text encoding. It's how email attachments survive 1980s mail relays. It's how images embed inside CSS. It's the middle part of every JWT. Understanding it makes a lot of plumbing make sense.

Last reviewed 27 April 2026·Source: RFC 4648 (base64 / base64url / base32 / base16)

What problem does it solve?

Many systems handle text safely but mangle binary. Email gateways were designed to pass 7-bit ASCII reliably; some flipped the high bit, dropped null bytes, or rewrote bytes that looked like control codes. To send binary through such a system, you have to encode it as printable text first.

Base64 picks 64 ASCII characters that survive almost any text-handling system: A-Z a-z 0-9 + /, plus = for padding. 64 = 2⁶, so each base64 character carries exactly 6 bits of data. Three input bytes (24 bits) → four output characters (24 bits of data). Always.

The encoding mechanic

Take three bytes:

Bytes:    M           a           n
ASCII:    01001101    01100001    01101110

Concat:   010011 010110 000101 101110

Map:        S      W      F      u
            ↓      ↓      ↓      ↓
Lookup table: A=0, B=1, ..., Z=25, a=26, ..., z=51, 0=52, ..., 9=61, +=62, /=63

"Man" → "TWFu" — that's the canonical example.

Padding

What if the input length isn't a multiple of 3?

1 leftover byte: encode it (8 bits → 2 chars), pad with ==
2 leftover bytes: encode them (16 bits → 3 chars), pad with =

So encoded output length is always a multiple of 4. The = tells decoders "those bits are padding, ignore them."

The 33% penalty

Three bytes in, four bytes out: 33.33% growth. A 30 KB image becomes 40 KB of base64 text. This is the cost you pay for ASCII-safety — fundamentally inherent to the 6-bits-per-output-char design. There's no way to do better with the same alphabet.

Other encodings exist with smaller penalties (base85 / Ascii85 has ~25% growth at the cost of using more punctuation characters that don't always survive transit), but base64 is the universal compromise.

Where base64 actually shows up

1. MIME / email attachments

Every email attachment is base64-encoded inside the SMTP message body. The Content-Transfer-Encoding: base64 header tells the recipient how to decode. This is the original use case (RFC 2045, 1996).

2. Data URLs

Embed binary directly in HTML/CSS/JSON: data:image/png;base64,iVBORw0KGgo.... Skips an HTTP round-trip for tiny assets. The JustKit image-to-base64 tool does this conversion.

3. JWT

JWT's three parts (header, payload, signature) are each base64url-encoded (the URL-safe variant — see below). The decoded header and payload are JSON; the signature is a binary hash. Decode any JWT to see this in action.

4. HTTP Basic Auth

Authorization: Basic dXNlcjpwYXNz — that's base64("user:pass"). It's not encryption — it's just encoding. Anyone capturing the traffic can decode it. Always use HTTPS with Basic Auth.

5. SSH and TLS

Public keys (ssh-rsa AAAAB3NzaC1...) and PEM-encoded certificates use base64 to wrap binary key material in copy-pasteable text. Most certificate files start with -----BEGIN CERTIFICATE----- followed by base64 lines.

6. Webhooks and APIs

When a binary payload (image, file) needs to fit in a JSON field, base64 is the standard. Even though JSON in theory supports any Unicode string, base64 avoids escaping issues with control characters or non-UTF-8 bytes.

Standard vs URL-safe (base64 vs base64url)

Standard base64 uses + and /. Both are problematic in URLs (and filenames): + means space when URL-decoding, and / is the path separator. The base64url variant (RFC 4648 section 5) substitutes:

+ → -
/ → _
padding = usually omitted entirely (length carries the info)

This is what JWT uses. The JustKit base64 tool supports both variants.

What base64 is NOT

Not encryption. Anyone with the encoded string can decode it instantly. Don't use base64 to "hide" passwords or secrets.
Not compression. Output is always larger than input.
Not a hash. It's reversible — encoding and decoding produce identical bytes.
Not safe for binary identity comparison. Different base64 implementations may differ on whether to add padding, line-break every N characters (RFC 2045 says yes; RFC 4648 says optional). Two semantically identical messages can be byte-different.

Decoding tip: skip whitespace

Most base64 decoders silently ignore whitespace (spaces, newlines, tabs). This is by design — many transports insert line breaks every 76 characters (the MIME convention). When in doubt, strip whitespace before decoding manually.

JustKit's role

JustKit has two base64 tools: text base64 for arbitrary strings (with URL-safe toggle) and image-to-base64 for files / data URLs. Both run entirely in your browser — content stays on your machine.