Base64 Encoding Explained: How It Works and When to Use It

Base64 is a binary-to-text encoding scheme. It takes arbitrary binary data — bytes that could represent an image, a PDF, a compressed archive, or any sequence of bits — and converts it into a string composed entirely of printable ASCII characters. The "64" in the name refers to the size of the character alphabet used in the output.

The 64-character alphabet

The standard Base64 alphabet consists of 65 characters (64 for encoding plus one for padding):

A-Z  (indices  0-25)   26 characters
a-z  (indices 26-51)   26 characters
0-9  (indices 52-61)   10 characters
+    (index   62)        1 character
/    (index   63)        1 character
=    (padding)           1 character

Every character in this alphabet is safe to include in text-based protocols without being misinterpreted as a control character, a line break, or a protocol delimiter. That property is the entire reason Base64 exists.

How the algorithm works, step by step

The encoding process operates on groups of three bytes at a time. Here is what happens to each group:

1. Take 3 bytes (24 bits) of input. If your input is the string Man, the ASCII values are 77, 97, 110 — which in binary is 01001101 01100001 01101110.

2. Split the 24 bits into four 6-bit groups. Those same 24 bits become 010011 010110 000101 101110. Each 6-bit group can represent a value from 0 to 63 — exactly the range needed to index into the 64-character alphabet.

3. Map each 6-bit value to a Base64 character. The values 19, 22, 5, 46 map to T, W, F, u. So Man encodes to TWFu.

4. Repeat for every 3-byte group until the entire input is processed.

Padding with the equals sign

Input data is not always a multiple of 3 bytes. When it falls short, Base64 pads the output with = characters to signal how many bytes were missing:

"M"    ->  "TQ=="    (1 byte input, 2 padding chars)
"Ma"   ->  "TWE="    (2 bytes input, 1 padding char)
"Man"  ->  "TWFu"    (3 bytes input, no padding needed)

The padding ensures the decoder knows exactly how many bytes to reconstruct. Some implementations (notably URL-safe Base64) omit padding since the decoder can infer the missing bytes from the string length, but the standard RFC 4648 specification includes it.

The fundamental problem Base64 solves is straightforward: many communication protocols and data formats were designed to handle text, not arbitrary binary data. When you need to send binary content through a text-only channel, you need a way to represent those bytes using only characters the channel can handle safely.

The problem with raw binary in text protocols

Consider what happens if you try to embed a JPEG image directly inside a JSON string. The image file contains byte values across the entire 0-255 range. Some of those bytes correspond to control characters (null bytes, line feeds, carriage returns) that JSON parsers would interpret as structural elements or reject entirely. Others might coincide with the quotation marks or backslashes that JSON uses as delimiters. The data would be corrupted before it ever reached the other end.

The same problem applies to email (SMTP was designed for 7-bit ASCII text), HTTP headers (which cannot contain arbitrary binary), XML documents, and many other text-based formats. Base64 solves this by ensuring every byte of the output is a safe, printable ASCII character that will not be mangled by any of these protocols.

Why 64 characters specifically?

The choice of 64 is a power of two (2^6 = 64), which makes the bit-splitting arithmetic clean and efficient. Using 6 bits per character keeps the encoding overhead manageable at around 33%. A smaller alphabet (like Base16/hex, which uses 4 bits per character) would double the size of the encoded output. A larger alphabet would require characters that are not universally safe across protocols. Base64 hits the sweet spot between compactness and compatibility.

Data URIs in HTML and CSS

Data URIs let you embed small files directly in markup instead of referencing an external URL. This eliminates an HTTP request, which can improve page load performance for small assets like icons, logos, and SVGs:

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

/* In CSS */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bW...");

This technique is best for assets under 10 KB or so. For larger files, the 33% size overhead outweighs the benefit of avoiding an extra request, and caching becomes impossible since the data is inlined.

API authentication headers (HTTP Basic Auth)

HTTP Basic Authentication encodes credentials as a Base64 string in the Authorization header:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

// "dXNlcm5hbWU6cGFzc3dvcmQ=" decodes to "username:password"

This is a critical point: the credentials are encoded, not encrypted. Anyone who intercepts this header can decode it instantly. Basic Auth should only be used over HTTPS, where TLS provides the actual encryption layer.

Email attachments (MIME encoding)

Email was one of the original motivations for Base64. The SMTP protocol only supports 7-bit ASCII, so binary attachments (images, PDFs, ZIP files) are Base64-encoded and embedded in the email body using MIME (Multipurpose Internet Mail Extensions). Your email client handles this transparently — it encodes attachments on send and decodes them on receive.

JWT payloads

JSON Web Tokens use a URL-safe variant of Base64 (base64url) to encode the header and payload segments. When you see a JWT like eyJhbGci...eyJzdWIi...SflKxwRJ..., the first two dot-separated segments are base64url-encoded JSON objects. You can decode them with any Base64 decoderto inspect the token's claims without needing the signing key.

Embedding binary data in JSON and XML

APIs sometimes need to include binary content — a thumbnail image, a PDF receipt, a cryptographic signature — inside a JSON or XML response. Since neither format supports raw binary, the convention is to Base64-encode the binary data and include it as a string field. Many cloud provider APIs (AWS, Google Cloud, Azure) use this pattern for certificate data, encryption keys, and file uploads.

This misconception is common enough to warrant its own section. Base64 encoding provides zero security. None. It is a fully reversible transformation that requires no key, no password, and no secret of any kind.

If you Base64-encode a password and store it in a config file, you have not protected that password. You have made it look slightly less readable to a human, but any developer (or script, or LLM) can decode it in under a second. The same applies to API keys, tokens, personal data, and any other sensitive information.

Base64 is an encoding — a way to represent data in a different format. Encryption is a transformation that requires a key to reverse. They solve completely different problems:

Encoding (Base64):    reversible by anyone, no key needed
Encryption (AES):     reversible only with the correct key
Hashing (SHA-256):    not reversible at all (one-way function)

If you need to protect data in transit, use TLS. If you need to protect data at rest, use proper encryption (AES-256, for example). If you need to store passwords, use a hashing algorithm designed for that purpose (bcrypt, scrypt, Argon2). Base64 is not a substitute for any of these.

Standard Base64 uses + and / as two of its 64 characters, and = for padding. All three of these have special meaning in URLs: the plus sign represents a space in query parameters, the slash is a path separator, and the equals sign is a key-value delimiter.

URL-safe Base64 (defined in RFC 4648 as "base64url") replaces these characters:

Standard:   +  /  =
URL-safe:   -  _  (padding often omitted)

You should use URL-safe Base64 whenever the encoded string will appear in a URL, a filename, or any context where +, /, or = could cause parsing problems. JWTs use base64url for exactly this reason — tokens frequently appear in URL query parameters and HTTP headers.

Base64 encodes every 3 bytes as 4 characters. That means the output is always 4/3 the size of the input — a 33.3% increase. For small payloads, this is negligible. For larger data, it adds up:

Original size    Base64 size     Overhead
100 bytes        136 bytes       +36 bytes
10 KB            13.3 KB         +3.3 KB
1 MB             1.33 MB         +330 KB
100 MB           133 MB          +33 MB

The overhead matters most in these scenarios: embedding large images as data URIs in HTML (each page load transfers 33% more data), storing Base64-encoded files in databases (wastes storage and memory), and transmitting large binary payloads through JSON APIs when a binary transfer mechanism (multipart upload, presigned URLs) would be more efficient.

For typical use cases — auth headers, small icons, JWT tokens, configuration values — the overhead is too small to worry about. Use Base64 when it makes the architecture cleaner. Avoid it when you are encoding megabytes of data that could be transferred as raw binary.

JavaScript (Browser)

// Encode
const encoded = btoa("Hello, World!");
// "SGVsbG8sIFdvcmxkIQ=="

// Decode
const decoded = atob("SGVsbG8sIFdvcmxkIQ==");
// "Hello, World!"

// Handle Unicode (btoa only works with Latin-1)
const unicodeEncode = btoa(
  new TextEncoder().encode("Hello ").reduce(
    (s, b) => s + String.fromCharCode(b), ""
  )
);

JavaScript (Node.js)

// Encode
const encoded = Buffer.from("Hello, World!").toString("base64");

// Decode
const decoded = Buffer.from(encoded, "base64").toString("utf-8");

// URL-safe variant
const urlSafe = Buffer.from("Hello, World!").toString("base64url");

Python

import base64

# Encode
encoded = base64.b64encode(b"Hello, World!").decode("ascii")
# "SGVsbG8sIFdvcmxkIQ=="

# Decode
decoded = base64.b64decode("SGVsbG8sIFdvcmxkIQ==").decode("utf-8")
# "Hello, World!"

# URL-safe variant
url_safe = base64.urlsafe_b64encode(b"Hello, World!").decode("ascii")

Command line

# macOS
echo -n "Hello, World!" | base64
echo "SGVsbG8sIFdvcmxkIQ==" | base64 --decode

# Linux
echo -n "Hello, World!" | base64
echo "SGVsbG8sIFdvcmxkIQ==" | base64 -d

# Encode a file
base64 < image.png > image.b64

Or skip the terminal entirely and use a browser-based Base64 encoder/decoder for quick one-off conversions. Paste the string, get the result, copy it out — no need to remember which flag is -d versus --decode.

In practice, you will decode Base64 far more often than you encode it. Most encoding happens automatically — your HTTP client library encodes Basic Auth headers, your email client encodes attachments, your frontend build tool encodes inlined assets. What lands on your desk as a developer is a Base64 string you need to inspect or debug.

Common decoding scenarios

Debugging API responses: A webhook payload contains a Base64-encoded body that you need to read. Paste it into a decoder to see the raw JSON or XML inside.

Inspecting JWTs: A user reports an authentication error. You grab the JWT from the request logs, decode the payload segment, and immediately see that the token expired two hours ago or that it is missing a required scope claim.

Reading configuration values: Kubernetes Secrets store values as Base64. When troubleshooting a deployment, you decode the secret to verify that the connection string or API key is what you expect.

Common encoding scenarios

Preparing auth headers: You are testing an API with curl and need to construct a Basic Auth header manually. Encode username:password to Base64 and paste it into the header.

Embedding small assets: You want to inline a 2 KB SVG icon as a data URI in your CSS to eliminate a network request. Encode the file and construct the data URI string.

Creating Kubernetes Secrets: You need to add a new secret to a YAML manifest. Encode the value and paste it in. (Or use kubectl create secret, which handles the encoding for you.)

Base64 is a useful tool, but it gets overused. Here are situations where it is the wrong choice:

Storing large files in databases. Base64-encoding a 10 MB file and storing it in a database text column wastes 33% more storage, kills query performance, and bypasses the file storage systems (S3, GCS, Azure Blob) that are designed for this purpose. Use object storage and store a URL reference instead.

Embedding large images in HTML. A 200 KB image inlined as a data URI becomes 266 KB of Base64 text inside your HTML. It cannot be cached independently, it blocks rendering while the browser decodes it, and it inflates your document size. Serve images as separate files.

Obfuscating sensitive data.Repeating for emphasis: Base64 is not security. If your goal is to make something "harder to read" by encoding it, you are building a false sense of security. Use actual encryption.

Transferring files between services. If both the sender and receiver can handle binary data (which most modern systems can), there is no reason to add the Base64 overhead. Use multipart form uploads, binary streams, or presigned URLs for file transfers.

When the protocol already handles binary. HTTP response bodies, WebSocket messages, gRPC, and most modern protocols support binary content natively. Base64-encoding data that will travel through a binary-safe channel is unnecessary overhead.

Property            Value
------------------------------------------------------
Alphabet            A-Z, a-z, 0-9, +, / (standard)
                    A-Z, a-z, 0-9, -, _ (URL-safe)
Padding character   = (may be omitted in URL-safe)
Input group size    3 bytes (24 bits)
Output group size   4 characters (24 bits)
Size overhead       ~33% (4/3 ratio)
Security            None (fully reversible, no key)
RFC                 4648 (standard), 2045 (MIME)
Encoding type       Binary-to-text