Base64 Is Not Encryption: What It Actually Does

Updated 2026-08-31 · 3 min read

Encoding vs encryption

Encoding changes the representation of data so it can travel safely through a channel; encryption changes the meaning so only a key holder can read it. Base64 needs no key, so anyone who sees the string can decode it in one second. It provides zero confidentiality.

What Base64 is genuinely for

• Embedding images or fonts in CSS/HTML as data URIs
• Sending binary blobs inside JSON or XML, which are text-only formats
• Email attachments via MIME
• HTTP Basic auth headers (which is why Basic auth requires HTTPS)
• Encoding JWT header and payload segments

The 33% size cost

Base64 turns every 3 bytes into 4 ASCII characters, growing payloads by about a third. That is why large images should be served as files with caching rather than inlined into CSS, where they bloat the render-blocking stylesheet.

What to use when you actually need secrecy

Use TLS in transit, AES-GCM or libsodium for data at rest, and a secrets manager for credentials. If you need to prove a value was not altered, sign it (HMAC) rather than encoding it.

Encoding, hashing, encryption and signing

Four operations get confused constantly, and mixing them up is how secrets end up exposed. Encoding (Base64, URL-encoding, hex) is reversible with no key and provides zero protection. Hashing (SHA-256, bcrypt, Argon2) is one-way and used to store passwords or fingerprint content. Encryption (AES-GCM, ChaCha20) is reversible only with a key and provides confidentiality. Signing (HMAC, RSA, Ed25519) proves origin and integrity but leaves the data readable.

Ask what property you need — secrecy, integrity, or transport safety — and the right primitive follows immediately.

How the encoding actually works

Base64 takes three bytes (24 bits), splits them into four 6-bit groups, and maps each group to one character from a 64-character alphabet of A–Z, a–z, 0–9, + and /. When the input length is not a multiple of three, one or two = characters pad the output.

That is the whole algorithm — no key, no randomness, no state. It is also why the output grows by exactly one third, and why you can recognise Base64 by its character set and the trailing equals signs.

Base64 and Unicode

Base64 operates on bytes, not characters, so text must be encoded to bytes first — practically always UTF-8. In older JavaScript, btoa("café") throws because the string contains a character outside Latin-1. The modern approach is btoa(String.fromCharCode(...new TextEncoder().encode(str))), or simply using a tool that handles UTF-8 correctly.

Get this wrong and emojis, accents and non-Latin scripts come back as mojibake after a round trip that looked successful.

When inlining is worth the 33%

Data URIs remove an HTTP request, which used to matter a great deal. Over HTTP/2 and HTTP/3 the request itself is cheap, so inlining is now only worth it for very small assets — icons under roughly 2 KB, or a single critical logo needed before the first paint.

• Inline: tiny SVG icons, a 1×1 tracking pixel, a critical above-the-fold logo
• Do not inline: photographs, web fonts, anything reused across pages, anything over a few kilobytes
• Remember that inlined assets cannot be cached separately — they are re-downloaded with every change to the file that contains them

Where people go wrong in production

The most common mistake is treating a Base64 blob in a URL, cookie or hidden form field as tamper-proof. Users can decode it, change the user id inside, re-encode it and send it back. If a value must not be altered, sign it and verify the signature server-side.

The second most common mistake is logging Base64 payloads under the assumption they are opaque. Log aggregation systems then hold decodable credentials and personal data indefinitely.

Encode or decode safely

The Base64 Encoder & Decoder handles full UTF-8 including emojis and runs entirely in your browser, so nothing you paste is transmitted. To inspect an auth token instead, use the JWT Decoder.

Frequently asked questions