Why Binary-to-Text Encoding Exists

Computers store all data as binary — sequences of 0s and 1s grouped into bytes (8-bit values, 0–255). Most text-based protocols and formats, however, can only safely represent a subset of those byte values. Early email protocols (SMTP), HTTP headers, and XML/JSON were designed for ASCII text and either cannot transmit arbitrary binary bytes at all, or treat certain byte sequences as control characters with special meanings.

Base64 solves this problem by converting binary data into a string of safe, printable ASCII characters that any text-based system can handle without misinterpretation. The formal specification is RFC 4648.

The Base64 Alphabet

Base64 uses 64 printable ASCII characters to represent all possible 6-bit values (26 = 64). The standard Base64 alphabet is:

  • Uppercase letters A–Z (26 characters, values 0–25)
  • Lowercase letters a–z (26 characters, values 26–51)
  • Digits 0–9 (10 characters, values 52–61)
  • + (value 62)
  • / (value 63)

The padding character = is not part of the alphabet — it is used to pad the output to a multiple of 4 characters.

The Encoding Process: 3 Bytes → 4 Characters

Base64 works on groups of 3 bytes (24 bits) at a time. It takes those 24 bits and splits them into four 6-bit groups. Each 6-bit group maps to one character in the Base64 alphabet. This is why Base64 always produces output that is a multiple of 4 characters.

The transformation:

  • Input: 3 bytes (24 bits)
  • Split into: four 6-bit groups
  • Map each to: one Base64 character
  • Output: 4 ASCII characters

A Worked Example

Let's encode the string Man (a classic example):

ASCII values: M = 77, a = 97, n = 110

In binary:

  • M = 01001101
  • a = 01100001
  • n = 01101110

Combined 24 bits: 010011010110000101101110

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

Decimal values: 19, 22, 5, 46

Base64 characters: T, W, F, u

Result: TWFu

You can verify this with the MDN Base64 documentation or by running btoa("Man") in any browser console.

Browser functions: JavaScript provides two built-in functions for Base64: btoa() encodes binary strings to Base64, and atob() decodes Base64 back to binary strings. For Unicode text, you need to handle encoding manually as these functions work on byte values, not multi-byte characters.

Padding with =

Base64 works in groups of 3 bytes. When the input length is not a multiple of 3, the final group needs padding:

  • If 1 byte remains: padded to 3 bytes, produces 2 Base64 characters + ==
  • If 2 bytes remain: padded to 3 bytes, produces 3 Base64 characters + =
  • If 0 bytes remain (exact multiple of 3): no padding needed

For example, encoding M (one byte, 77, 01001101): the bits are padded to form a full group, producing TQ==.

Padding ensures the output length is always a multiple of 4 characters, which some systems require for correct parsing.

The Base64URL Variant

Standard Base64 uses + and /, both of which have special meanings in URLs and file paths. Base64URL (defined in RFC 4648 Section 5) modifies the alphabet:

  • + is replaced by -
  • / is replaced by _
  • Padding (=) is typically omitted

Base64URL-encoded data can be safely included in URL parameters, filenames, and HTTP headers without percent-encoding. This is why JWT tokens (which are Base64URL-encoded) can appear directly in URLs and Authorization headers.

Learn more about how JWTs use Base64URL in our complete JWT guide.

Size Overhead

The 3-bytes-to-4-characters conversion means Base64 output is always approximately 33% larger than the input. More precisely:

  • Output characters = ⌈n / 3⌉ × 4 (where n is input byte count)
  • A 100-byte input produces 136 characters of Base64
  • A 1MB image produces approximately 1.37MB of Base64

This size overhead must be considered when deciding whether to use Base64. For small inline assets (icons, small images), the trade-off is worth it to eliminate HTTP requests. For large assets, the size increase and loss of caching outweigh any convenience benefit.

Use Cases

Data URIs

Images and fonts can be embedded directly in HTML or CSS using Base64 data URIs:

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

This eliminates the HTTP request for the resource but increases the HTML/CSS file size.

Email Attachments (MIME)

The MIME standard uses Base64 to encode binary file attachments in email messages. Email was originally designed for ASCII text only; Base64 allows any file to be sent as part of a text-based email message.

JWT Tokens

All three parts of a JWT (header, payload, signature) are Base64URL-encoded. This allows the token to be safely transmitted as a URL parameter or HTTP header value without encoding issues.

HTTP Basic Authentication

HTTP Basic Auth encodes credentials as Base64(username:password) in the Authorization header:

Authorization: Basic dXNlcjpwYXNzd29yZA==

Note: This provides no security — the encoded value is trivially reversible. HTTPS (TLS) provides the actual transport security.

Binary Data in Text Formats

JSON and XML cannot directly contain binary bytes. Base64 allows images, cryptographic keys, and other binary data to be embedded as strings in JSON or XML documents.

Base64 is Not Encryption

This is the most important thing to understand about Base64. Encoding is reversible without any key. Anyone who sees a Base64 string can decode it instantly using any Base64 decoder. There is no secret, no key, no security.

Do not use Base64 to "hide" sensitive data. Do not store passwords as Base64 and call it encryption. The only legitimate security-related use of Base64 is as a transport encoding — it makes binary data safe to transmit over text-based channels, but the actual security comes from TLS/HTTPS, not from the encoding itself.

Try It Free — No Signup Required

Encode and decode Base64 instantly in your browser. Supports text, URLs, and binary data — all client-side.

Open Base64 Encoder