How binary data survives in a text-only world. The encoding you see in JWTs, PEM certificates, SSH keys, and API tokens.
Cryptographic keys, certificates, and encrypted data are raw bytes. Many systems that need to carry this data (JSON, HTTP headers, emails, URLs) only support text. Base64 is the bridge.
Hexadecimal doubles the size of your data: every byte becomes two characters. A 256-bit key takes 64 hex characters. Base64 is more efficient. It encodes 3 bytes into 4 characters, a 33% size increase instead of 100%. That same 256-bit key takes just 44 Base64 characters.
The tradeoff is simplicity. Hex maps one byte to two characters, easy to read at a glance. Base64 works on 3-byte groups, which makes it more compact but harder to decode in your head.
Base64 uses a carefully chosen set of 64 characters that are safe in virtually every text-based system. Each character represents a 6-bit value (), compared to hex where each character represents 4 bits.
64 characters, each representing a 6-bit value (0 to 63). Hover over any character to see its index and binary value.
The choice of these 64 characters is not arbitrary. Letters, digits, plus, and slash are all safe in most text protocols. A variant called base64url swaps + and / for - and _ to avoid conflicts in URLs. This is what JWTs use.
The algorithm is simple: take 3 bytes (24 bits), split them into four 6-bit groups, and look up each group in the alphabet. If the input is not a multiple of 3 bytes, pad with = signs.
Take 3 input bytes and concatenate their bits into a single 24-bit stream.
Split those 24 bits into four 6-bit groups. Each group is a number from 0 to 63.
Look up each number in the Base64 alphabet to get the output character. If the last group has fewer than 3 bytes, pad the output with = signs.
Type text and watch each 3-byte group get split into four 6-bit sextets, each mapped to a Base64 character.
Base64 always outputs in groups of 4 characters. If the input is not a multiple of 3 bytes, the last group is incomplete. The = signs tell the decoder exactly how many bytes were in the final group, so it can strip the zero-padding during decoding.
1 byte of input → 2 Base64 characters + ==. 2 bytes → 3 characters + =. 3 bytes → 4 characters, no padding needed. The pattern then repeats.
You encounter Base64 constantly without necessarily realizing it. Here are the most common places it shows up in cryptography and web development.
-----BEGIN CERTIFICATE----- MIIBIjANBgkqhkiG9w0BAQE... -----END CERTIFICATE-----
TLS certificates and private keys are DER-encoded binary wrapped in Base64 between header/footer lines. Every HTTPS connection starts with one.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.signature
Each JWT segment is base64url-encoded JSON. The header and payload are not encrypted, just encoded. Anyone can decode them.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB... user@host
The long string after ssh-rsa is Base64-encoded binary containing the key type and the actual public key parameters.
sk-ant-api03-Wk7x2F4...
Many API providers Base64-encode or use Base64 variants for their keys. It makes binary identifiers safe to copy, paste, and transmit in HTTP headers.
Paste any Base64 string you find in the wild and see what is actually inside.
Paste any Base64 string and see the raw bytes underneath. Try one of the real-world examples below.
This is worth emphasizing because it is one of the most common mistakes in software development.
Base64 is a reversible encoding. There is no key, no secret, no security. Anyone who sees a Base64 string can decode it instantly. The JWT payload eyJzdWIiOiIxMjM0NTY3ODkwIn0 is not hidden. It is just {"sub":"1234567890"} written in a URL-safe format.
If you need data to be secret, encrypt it. If you need data to survive a text-only channel, encode it. Base64 does the second thing. Cryptographic algorithms from the encryption chapter do the first.