Base64 Explained: How Encoding Works, With Examples

Q: Is Base64 encryption?

No. Base64 is not encryption. It is a binary-to-text encoding. There is no key, no secret — anyone who sees a Base64 string can decode it instantly.

Q: How much larger is Base64 output than input?

Base64 output is always 33% larger than the input (rounded up to the nearest multiple of 4). 3 bytes of input produce 4 characters of output.

Q: What is URL-safe Base64?

URL-safe Base64 (RFC 4648) replaces + with - and / with _, and typically omits padding. This is the variant used in JWTs and modern web APIs.

Base64 is everywhere in software. It is the encoding your JWT uses, the way your browser embeds images in CSS, the format of your SSH public key file, and the encoding of every MIME email attachment. But what is it, really?

What Base64 is not

Base64 is not encryption. It is not a hash. It is not compression. It is a binary-to-text encoding — a way to represent arbitrary binary data using only printable ASCII characters.

There is no key, no secret, no obfuscation. Anyone who sees a Base64 string can decode it instantly. If you need security, use encryption (AES, ChaCha20). If you need integrity, use a hash (SHA-256).

The 64 characters

Base64 uses 64 characters to encode data: the uppercase letters A-Z, lowercase a-z, digits 0-9, and two more characters (usually + and /). The 65th character, =, is used for padding.

Why these characters? Because they are all printable, all safe to transmit over text-only channels (email, URLs, JSON), and they exist in every character encoding (ASCII, UTF-8, Latin-1).

How it works

Base64 takes binary data in chunks of 3 bytes (24 bits) and splits each chunk into 4 groups of 6 bits. Each 6-bit group (0-63) is mapped to one of the 64 characters.

3 bytes → 4 characters. The output is always 33% larger than the input (rounded up).

If the input is not a multiple of 3 bytes, the output is padded with = characters to make it a multiple of 4.

URL-safe Base64

Standard Base64 uses + and /, which have special meaning in URLs and file names. The URL-safe variant (RFC 4648 §5) replaces them with - and _, and typically omits the padding.

This is the variant used in JWTs, JWS, JWE, and most modern web APIs.

Common uses

JWT tokens — header, payload, signature are all Base64URL-encoded JSON
Data URIs — data:image/png;base64,iVBORw0K... embeds images in HTML/CSS
MIME email — attachments are Base64-encoded so they survive text-only mail servers
SSH keys — -----BEGIN RSA PUBLIC KEY----- contains Base64-encoded ASN.1
Basic auth — Authorization: Basic dXNlcj...ode> is just base64(\"user:pass\")


  Git objects — Git stores content as Base64 internally



Performance note
Base64 has a 33% size overhead. For large binary blobs (images, video), prefer actual binary transfer (multipart/form-data, raw bytes over WebSocket). Use Base64 only when you must fit binary data into a text-only context.

Encode and decode with our Base64 tool.


  Frequently Asked Questions
  
    Q: Is Base64 encryption?
    No. Base64 is not encryption. It is a binary-to-text encoding. There is no key, no secret —anyone who sees a Base64 string can decode it instantly. For security, use AES or ChaCha20 encryption.
  
  
    Q: How much larger is Base64 output than input?
    Base64 output is always 33% larger than the input (rounded up to the nearest multiple of 4). 3 bytes of input produce 4 characters of output. MDN has a full explanation.
  
  
    Q: What is URL-safe Base64?
    URL-safe Base64 (RFC 4648) replaces + with - and / with _, and typically omits padding. This is the variant used in JWTs and modern web APIs.