Delimiter.live
Comparison

Base64 vs Encryption

Base64 converts binary data into 64 printable ASCII characters so it can travel safely through text-only channels. It is reversible by anyone with no key, so it provides no confidentiality whatsoever. Encryption transforms data so that only a holder of the correct key can recover it. Base64 solves a transport problem; encryption solves a secrecy problem.

Base64 Encoder and Decoder

Encode text to Base64 or decode it back, including URL-safe.

Open the tool

This comparison exists because the mistake is common and consequential. Base64-encoded text looks scrambled, and looking scrambled is often mistaken for being protected. It is not. Decoding requires no key, no secret and no effort — every language has a one-line function for it.

Base64 has a real and useful job. It just is not security.

What Base64 is actually for

Many channels were designed for text and mangle arbitrary bytes: email bodies, JSON string values, URLs, HTTP headers, XML documents. Base64 maps arbitrary binary onto 64 characters that survive all of them intact, at a cost of roughly 33% more size.

  • Attaching binary files to email (MIME).
  • Embedding images directly in HTML or CSS as data: URIs.
  • Carrying binary values inside JSON or XML, which have no binary type.
  • Encoding credentials for HTTP Basic authentication — which is exactly why Basic auth requires HTTPS.
  • The header and payload segments of a JWT.

Why it protects nothing

Encoding is a public, reversible mapping. There is no key. Anyone who receives Base64 text can decode it instantly, and tooling to do so is universal. If an attacker can see the encoded value, they can see the original.

What to use instead

For confidentiality in transit, use TLS. For confidentiality at rest, use AES-GCM or another authenticated cipher with a properly managed key. For proving data has not been altered, use a signature or HMAC. For storing passwords, use bcrypt, scrypt or Argon2 — and note that none of those is encryption either, since passwords should never be recoverable.

They often appear together

Encryption produces binary output, which frequently needs to travel through a text channel — so encrypted data is very often Base64-encoded afterwards. Seeing Base64 wrapped around a value tells you nothing about whether the value underneath was encrypted.

Example

Decoding needs no key. This is an encoding, not protection.

Base64

bXktc2VjcmV0LXBhc3N3b3Jk

Decoded

my-secret-password

Frequently asked questions

Is Base64 encryption?
No. It is an encoding: a public, reversible mapping with no key involved. Anyone can decode it instantly. Encryption requires a key and is designed so that data cannot be recovered without it.
Why does HTTP Basic authentication use Base64?
Only to make the username and password safe to put in a header, not to protect them. The credentials are recoverable by anyone who sees the request, which is precisely why Basic authentication must never be used without HTTPS.
Is it safe to put Base64 in a URL?
Not standard Base64, because + and / have meaning in URLs. Use the URL-safe variant, which substitutes - and _ instead. Remember that it is still readable by anyone who sees the URL, including server logs and browser history.
Why does Base64 make data bigger?
It represents three bytes with four characters, so output is about 33% larger than input, plus padding. That is the cost of restricting output to characters every text channel handles safely.
What are the = characters at the end?
Padding. Base64 works in three-byte blocks; when the input length is not a multiple of three, one or two = characters pad the final block. Some variants omit padding, which is why decoders generally tolerate its absence.

Tools used in this guide

All tools →
All guides →

Last reviewed .