Base64 Encoding Guide: What It Is, How It Works & When to Use It (2026)

What Is Base64 Encoding?

Base64 is a binary-to-text encoding scheme. It takes raw binary data — bytes that can include any value from 0 to 255 — and converts it into a string of 64 printable ASCII characters that can travel safely through text-only systems.

The name comes directly from the math: 64 possible characters, each representing 6 bits of data. Standardized as part of MIME (Multipurpose Internet Mail Extensions) in RFC 1341 in 1992, Base64 has been a foundational piece of internet infrastructure for over three decades.

Before Base64 (and MIME), email was strictly text-only. Attaching a photo, a PDF, or an executable was impossible — those files contain byte values that old mail servers would misinterpret or strip. Base64 solved that problem by encoding any binary file as text, making it safe to embed in an email body.

Why Base64 Exists: The ASCII Safety Problem

The internet was built on ASCII, a 7-bit encoding covering characters 0–127. Many older protocols — SMTP (email), HTTP headers, HTML attributes — were designed to handle only printable ASCII text. They choke on arbitrary binary bytes.

Consider a JPEG image. Its bytes might include values like 0xFF, 0x00, or 0xD9. Some of those values mean "end of file" or "line break" in certain protocols. Pass raw binary through an ASCII-only channel and the data gets corrupted.

Base64’s job is simple: take those unpredictable bytes and map them to a fixed set of 64 printable characters that every system understands. The result is larger, but it survives any text-safe transport layer intact.

How Base64 Encoding Works

The algorithm works in a tight three-step process:

1. Take 3 bytes of input (24 bits total).
2. Split into four 6-bit groups (since 24 ÷ 6 = 4).
3. Map each 6-bit value (0–63) to a character in the Base64 alphabet.

A Concrete Example: Encoding “Man”

The word “Man” in ASCII is three bytes:

Concatenated: 010011010110000101101110 (24 bits)

Split into four 6-bit groups: 010011 010110 000101 101110

Those values in decimal: 19, 22, 5, 46

Mapped to the Base64 alphabet: T, W, F, u → result: TWFu

You can verify this yourself: paste Man into our Base64 Encoder/Decoder and the output will be TWFu every time.

The Padding Character ( = )

Base64 processes input in 3-byte chunks. If the input length isn’t a multiple of 3, padding is added:

• 1 leftover byte → 2 Base64 characters + ==
• 2 leftover bytes → 3 Base64 characters + =
• 0 leftover bytes → no padding needed

The =sign is not a Base64 character — it’s purely a padding marker so the decoder knows the original length.

The Base64 Character Set

Every character in that set is safe in plain text, email bodies, and most programming contexts. That’s the entire point.

Common Use Cases

Email Attachments (MIME)

MIME — developed by Nathaniel Borenstein and Ned Freed and first published in 1992 — is the standard that lets email carry attachments. When you send a PDF or an image, your email client Base64-encodes the file and embeds it in the message body. The recipient’s client decodes it back. This is why email attachments can be ~33% larger than the original file.

Data URIs in HTML and CSS

A data URI embeds a file directly into HTML or CSS using Base64, eliminating a network request:

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

According to MDN, all modern browsers support data URIs. But they’re discouraged for large images: the 33% size overhead means more bytes to download, and the browser can’t cache the image separately from the page.

JWT Tokens

JSON Web Tokens — used in approximately 50% of modern web authentication systems according to JWT.io — use a URL-safe variant called Base64URL for their header and payload sections. A JWT looks like three Base64URL-encoded segments separated by dots: header.payload.signature.

The header and payload are just Base64-encoded JSON. Paste the middle segment of any JWT into a Base64 decoder and you’ll see the plain JSON claims. This is why JWTs must be transmitted over HTTPS — the contents are visible to anyone.

HTTP Basic Authentication

When a browser sends Basic Auth credentials, it Base64-encodes the username and password as username:password and puts the result in an HTTP header: Authorization: Basic dXNlcjpwYXNz. Again, this is encoding, not encryption — the credentials are trivially recoverable by anyone who intercepts the header. Always use HTTPS with Basic Auth.

Storing Binary Data in JSON or XML

JSON and XML are text formats. If you need to include binary data (an image thumbnail, a cryptographic signature, a compiled artifact) inside a JSON payload, Base64 is the standard way to do it. Most REST APIs that deal with file uploads use Base64-encoded fields for exactly this reason.

Base64 vs Encryption: A Critical Distinction

This is the most common misconception about Base64, and it matters.

Base64 has no secret key and no algorithm complexity. Decoding is O(n) and trivially implemented in any language. If you need to hide data from anyone, use real encryption. Base64 is purely a formatting tool.

The Size Overhead: Why Base64 Is ~33% Larger

As specified in RFC 4648, Base64 encodes 3 bytes as 4 characters. The math:

• 3 bytes = 24 bits of input
• 4 characters = 4 × 6 bits = 24 bits of output
• Size ratio = 4/3 ≈ 1.333

A 1 MB image becomes roughly 1.33 MB as Base64. A 10 KB JSON attachment in an email becomes ~13.3 KB. For small payloads this barely matters. For large file transfers or high-traffic APIs, the overhead adds up fast.

Padding adds at most 2 bytes (==), which is negligible. The real cost is the 4/3 ratio itself.

Base64URL: The URL-Safe Variant

Standard Base64 uses + and / characters, which have special meanings in URLs (+ means space, / separates path segments). Base64URL solves this by replacing:

• + → -
• / → _
• Padding = → omitted

The result can be placed directly in URLs, HTTP headers, and filenames without percent-encoding. JWTs, OAuth tokens, and many API keys use Base64URL for exactly this reason.

Base64 in Different Languages

No external library needed in any of these languages — Base64 is part of every standard library. For quick one-off conversions, our Base64 Encoder/Decoder handles it without writing any code.

Frequently Asked Questions

What is Base64 encoding?

Base64 is a binary-to-text encoding scheme that represents binary data using only 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). It converts every 3 bytes of binary into 4 characters, making binary data safe to transmit over systems that only handle text.

Is Base64 the same as encryption?

No. Base64 is encoding, not encryption. Anyone can decode Base64 data instantly — no key or password is needed. It provides zero security. Encryption (like AES-256) scrambles data so it can only be read with the correct key. Never use Base64 to protect sensitive information.

How do I encode a string in Base64?

In JavaScript, use btoa('your string') to encode and atob('encoded') to decode. In Python, use base64.b64encode(b'your string') and base64.b64decode(). Or just use a free online tool like hakaru’s Base64 Encoder/Decoder.

Why is Base64 data larger than the original?

Base64 groups every 3 bytes of input into 4 output characters. That’s a 4/3 ratio, meaning the output is always approximately 33% larger than the original. A 300-byte file becomes roughly 400 characters when Base64-encoded. This overhead is specified in RFC 4648.

What are data URIs in HTML?

A data URI embeds file content directly into HTML or CSS using Base64. For example: <img src="data:image/png;base64,iVBORw0KGgo..."> inlines an image without a separate HTTP request. MDN notes that all modern browsers support data URIs but recommends against using them for large images due to the 33% size overhead and lack of browser caching.

What is Base64URL and how is it different?

Base64URL is a URL-safe variant of Base64 used in JWT tokens and URLs. It replaces + with - and / with _, and omits the = padding character. This makes the encoded string safe to use directly in URLs and HTTP headers without percent-encoding.