What Is Base64 Encoding?

The one thing to know upfront

Base64 is encoding, not encryption. It is a reversible transformation that converts binary data into a safe text format. It offers no confidentiality. Anyone who has a Base64-encoded string can decode it instantly — no key, no password, no special knowledge required.

This point matters because Base64 strings look scrambled enough that people sometimes mistake them for encrypted data. They are not.

Why Base64 exists

Computers represent everything as binary — sequences of bytes. Most communication channels, however, were designed to carry text. Email systems, HTTP headers, URLs, HTML attributes, and many other text-based channels impose restrictions:

• Some bytes represent control characters that terminate a transmission.
• Some channels modify or strip certain byte values.
• Some protocols only reliably handle 7-bit ASCII characters.

Base64 sidesteps these problems by converting arbitrary binary data into a string that uses only 64 printable ASCII characters: A–Z, a–z, 0–9, +, and /, plus = as a padding character. That set is universally safe across text-based systems.

How encoding works

Base64 takes three bytes (24 bits) of input and maps them to four characters of output. Because every three bytes become four characters, the encoded output is always roughly 33% larger than the original input.

Example: encoding the ASCII string "Man"

So "Man" encodes to "TWFu".

Padding

When the input length is not a multiple of three, Base64 adds = characters to pad the output to a multiple of four:

• One leftover byte → two Base64 characters + ==
• Two leftover bytes → three Base64 characters + =

Base64URL

Standard Base64 uses + and / as its 62nd and 63rd characters. These characters have special meaning in URLs (+ means space, / separates path segments), which causes problems when embedding Base64 in a URL or query string.

Base64URL is a variant that replaces + with - and / with _, and typically omits the = padding. You will encounter Base64URL in JWTs (JSON Web Tokens), where the header and payload sections are Base64URL-encoded.

When decoding something from a URL or a JWT, make sure to use the Base64URL variant. Standard and Base64URL strings are not interchangeable.

Common use cases

Embedding binary data in text formats

Images, fonts, and other binary assets can be embedded directly in HTML or CSS as data URLs:

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

Email attachments (MIME)

Email protocols are text-based. The MIME standard uses Base64 to attach files — when you download a PDF from an email, your client likely decoded a Base64 stream.

HTTP Basic Authentication

The Authorization: Basic header encodes username:password as Base64:

Authorization: Basic YWxpY2U6c2VjcmV0

This is only safe over HTTPS. The credentials are trivially decoded, so Basic Auth without TLS provides no real protection.

JSON Web Tokens (JWTs)

A JWT's header and payload are Base64URL-encoded JSON objects. This is purely encoding — the contents are readable by anyone. Only the signature portion provides integrity verification.

API responses

Some APIs return binary data (images, documents, audio) as Base64 strings within a JSON field, avoiding the need for a separate file download.

Limitations

• Size overhead — Base64 output is ~33% larger than the original data. For large binary files, this overhead adds up.
• No security — Base64 provides no confidentiality or integrity. If you need to protect data, use actual encryption (e.g., AES) — not encoding.
• Not streaming-friendly — Base64 is typically applied to complete inputs; streaming chunked Base64 requires careful handling of chunk boundaries.

Quick reference

You can verify any of these using the Base64 Encoder tool — paste in text and see the encoded result instantly.