Base64 Is Not Encryption: How It Works, Common Myths, and Real Use Cases

The Conclusion First: Base64 Is Not Encryption

Open any Base64 decoder, paste a Base64 string, and the original content is instantly recovered. This demonstrates one thing: Base64 has no key, anyone can decode it, and it is not encryption in any meaningful sense.

Yet in real-world development, Base64 is still widely misused as a form of "lightweight encryption" — storing user data as Base64 in cookies, or treating Base64-encoded API parameters as a security measure. This is a dangerous misconception.

This article explains what Base64 actually is at a fundamental level, and where it genuinely belongs.

What Base64 Really Is: Binary to Printable Characters

Base64 is an encoding scheme, not an encryption algorithm. It has one purpose: convert arbitrary binary data into a string containing only printable ASCII characters.

Why is this conversion needed? Because many early protocols (such as SMTP for email, HTTP headers) could only transport plain text and could not handle raw binary data. Base64 was created to solve this compatibility problem.

The Character Set

Base64 uses 64 characters to represent data:

A-Z (26) + a-z (26) + 0-9 (10) + + (1) + / (1) = 64 characters

The = character is used as padding at the end to ensure the encoded output length is always a multiple of 4.

How the Encoding Works

The core idea: every 3 bytes (24 bits) of binary data are regrouped into four 6-bit groups, each mapped to one Base64 character.

Take the word Man as an example:

Characters:  M         a         n
ASCII:       77        97        110
Binary:      01001101  01100001  01101110

Regrouped (6 bits each):
010011  010110  000101  101110

Base64 characters:
T       W       F       u

Result: TWFu

Since 3 bytes become 4 characters, Base64-encoded data is roughly 33% larger than the original.

The Fundamental Difference from Encryption

In short: Base64 gives data a change of clothes; encryption puts a lock on it. Anyone can change the clothes back; the lock requires a key.

Where Base64 Actually Belongs

1. JWT (JSON Web Token)

This is one of the most common Base64 use cases today. A JWT consists of three parts, each Base64URL-encoded (a variant of Base64 that replaces + with -, / with _, and removes trailing =):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoding the first segment gives: {"alg":"HS256","typ":"JWT"}. The second gives: {"sub":"1234567890"}.

JWT security does not come from Base64 — it comes from the third segment's signature (an HMAC or RSA signature generated with a secret key). Base64 here simply allows JSON data to be safely embedded in HTTP headers.

⚠️ This means the JWT payload is fully readable by anyone. Never put passwords or sensitive secrets in the JWT payload.

2. Embedding Images in HTML/CSS

Converting an image to Base64 allows it to be written directly into HTML or CSS, eliminating an additional HTTP request:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

.icon {
  background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxu...');
}

Best for: Small icons, loading animations, email templates (email clients typically block external image URLs).

Not suitable for: Large images. Base64 increases file size by 33%, which significantly inflates page weight and slows loading.

3. Transmitting Binary Data in JSON or XML

JSON only supports text — it cannot directly contain binary data (such as file contents or image bytes). Base64-encoding binary data turns it into a string field that can live inside JSON:

{
  "filename": "report.pdf",
  "content": "JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwov..."
}

Many file upload APIs and AI model image input interfaces use exactly this approach.

4. HTTP Basic Authentication

The HTTP Basic Auth credential format is:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Decoded, this is simply username:password. Since it is trivially reversible, Basic Auth must always be used over HTTPS — otherwise it is effectively plaintext credential transmission.

5. Email Attachments

This is Base64's original use case. The MIME standard specifies that email attachment content be Base64-encoded so that binary files can travel through ASCII-only mail protocols.

Common Mistakes to Avoid

❌ Using Base64 to "Encrypt" Passwords

// Wrong — completely insecure
const encoded = btoa(password);

Anyone who obtains this string can call atob() to recover the original password instantly. Passwords must be processed with a proper hashing algorithm such as bcrypt or Argon2, never Base64.

❌ Using Base64 to "Hide" API Keys

Storing an API key as Base64 in frontend code does not make it more secure. An attacker who finds the string can decode it in seconds. API keys belong in backend environment variables and should never be exposed in client-side code.

❌ Using Base64 for Large File Transfers

Base64 increases payload size by 33%. For files of several megabytes or more, use multipart/form-data to transfer binary data directly instead of Base64-encoding it.

Online Tool

For quick Base64 encoding and decoding — or converting an image into a Base64 data URL — the Base64 Online Encoder/Decoder on toolshu.com supports UTF-8, GBK, Big5, and dozens of other character encodings, handling multilingual content correctly. All operations run locally in your browser with no data uploaded.