August 5, 2026

What Is Base64 Encoding and Why Do We Use It?

Learn what Base64 encoding is, how it converts binary to text, and why it's used for email attachments, data URIs, and more. Try our free Base64 encoder online.

By ToolSite5 min readguides

What Is Base64 Encoding?

Base64 encoding is a method for converting binary data into a plain-text representation using a set of 64 ASCII characters. It answers a simple problem: how do you transmit raw bytes through systems that only understand text, like email protocols or JSON payloads?

You take a sequence of bytes, split them into 6-bit chunks, and map each chunk to one of 64 safe characters: uppercase A-Z, lowercase a-z, digits 0-9, plus + and /. The result is a longer but transport-safe string. Base64 expands output by roughly 33 percent. Every 3 bytes of input become 4 ASCII characters.

How Base64 Encoding Works

Base64 processes input 3 bytes at a time. Three bytes equal 24 bits. Those 24 bits are divided into four 6-bit groups, and each group is mapped to a character from the Base64 alphabet:

Value  Char | Value  Char | Value  Char | Value  Char
 0      A   | 16      Q   | 32      g   | 48      w
 1      B   | 17      R   | 33      h   | 49      x
 2      C   | 18      S   | 34      i   | 50      y
 3      D   | 19      T   | 35      j   | 51      z
 4      E   | 20      U   | 36      k   | 52      0
 5      F   | 21      V   | 37      l   | 53      1
 6      G   | 22      W   | 38      m   | 54      2
 7      H   | 23      X   | 39      n   | 55      3
 8      I   | 24      Y   | 40      o   | 56      4
 9      J   | 25      Z   | 41      p   | 57      5
10      K   | 26      a   | 42      q   | 58      6
11      L   | 27      b   | 43      r   | 59      7
12      M   | 28      c   | 44      s   | 60      8
13      N   | 29      d   | 45      t   | 61      9
14      O   | 30      e   | 46      u   | 62      +
15      P   | 31      f   | 47      v   | 63      /

If the input is not evenly divisible by three, one or two = characters are appended as padding so the decoder knows how many bytes to expect.

Let's encode the word hello:

Original:  h    e    l    l    o
ASCII hex: 0x68 0x65 0x6C 0x6C 0x6F
Binary:    01101000 01100101 01101100 01101100 01101111

Group 1: 011010 000110 010101 101100 -> a G V s
Group 2: 011011 000110 1111____ ____ -> b G 8  =
         (padded with 4 zero bits)

The result is aGVsbG8=. Five bytes needed padding, so one = is added.

Try a simpler example, the string Ma (2 bytes):

M  a
01001101 01100001
-> 010011 010110 000100 _____ (= padded)
-> T     W     E     =
-> TWE=

And M alone (1 byte):

M
01001101
-> 010011 010000 ____ ____
-> T     Q     =     =
-> TQ==

Decoding: Reversing the Process

Decoding reverses each step. A Base64 decoder maps each character back to its 6-bit value, concatenates the bits into a byte stream, and discards any padding.

aGVsbG8= -> a(26) G(6) V(21) s(44) b(27) G(6) 8(60)
         -> 011010 000110 010101 101100 011011 000110 111100 (ignore padding bits)
         -> 01101000 01100101 01101100 01101100 01101111
         -> h        e        l        l        o

Most programming languages have built-in Base64 support:

import base64
encoded = base64.b64encode(b"hello")  # b'aGVsbG8='
decoded = base64.b64decode(encoded)   # b'hello'

const encoded = btoa("hello");   // "aGVsbG8="
const decoded = atob(encoded);   // "hello"

Why Not Just Send Raw Binary?

Many protocols that form the backbone of the internet were designed for text. A Base64-encoded string passes through them unchanged. Raw binary bytes do not.

Email (SMTP) was originally 7-bit ASCII only. A binary attachment like a .pdf sent as-is would be mangled by intermediate mail servers. Base64-encoding the file lets it travel inside the message body safely.

JSON does not have a binary type. If you need to include an image or a cryptographic key in a JSON API response, you Base64-encode it into a string.

Some protocols use line-length limits. Base64 encoders often insert line breaks every 76 characters to stay within MIME limits. When you see a .pem certificate file, those 64-character lines between -----BEGIN and -----END markers are Base64 with fixed-width wrapping.

Common Use Cases

Email attachments (MIME): Every file attachment in an email is Base64-encoded before transmission. The MIME standard specifies Content-Transfer-Encoding: base64 for this purpose.
Data URIs: You can embed small images directly in CSS or HTML using a data URI like data:image/png;base64,iVBORw0KGgo.... This avoids an extra HTTP request at the cost of a larger HTML file.
Storing binary in text fields: JSON Web Tokens (JWT) store metadata in Base64url-encoded segments. Certificate files (.pem) use Base64 between -----BEGIN and -----END markers.
URL-safe variants: Standard Base64 uses +, /, and =, characters that have special meaning in URLs. Base64url replaces + with -, / with _, and strips padding entirely. This variant is used in JWTs and some API tokens. When you see a JWT like eyJhbG...sw5c, the segments between the dots are Base64url, not standard Base64.

Base64 Is Not Encryption

A common misconception is that Base64 "encrypts" data. It does not. Base64 is a reversible encoding with no key. Anyone can decode a Base64 string back to its original bytes with a single command:

echo "aGVsbG8=" | base64 -d

Base64 provides zero confidentiality. It is an encoding, not an encryption algorithm. If you need to protect data, use a proper encryption standard like AES-GCM alongside Base64, never Base64 alone.

A related mistake is treating Base64 as a compression format. Base64 makes your data larger, not smaller. Each 3 bytes of input expands to 4 bytes of output. If you need to reduce size, compress first with gzip or brotli, then Base64-encode the compressed bytes.

Try it yourself: open the Base64 Encoder/Decoder and paste hello into the text input. Encode it and verify the output matches aGVsbG8=. Then decode it back to confirm the round-trip works. Try encoding a short sentence and observe the output length. It will always be longer than the input.