Base64 encoding explained

Base64 is a binary-to-text encoding that represents bytes with a 64-character alphabet. Each complete three-byte block becomes four characters, so long inputs grow by about one third before line wrapping or other protocol overhead¹.

Base64 appears in formats and protocols that need to carry bytes as text, including MIME email, data URLs, HTTP Basic authentication, JSON Web Signatures, and PEM-style certificate files.

Origins

RFC 989 described a printable encoding for Privacy Enhanced Mail (PEM) in 1987². It represented encrypted message data and signatures with characters that could pass through mail systems designed around restricted text.

Later PEM specifications retained the encoding, including RFC 1421 in 1993³. RFC 2045 then defined Base64 as a MIME content-transfer encoding for email bodies in 1996⁴. RFC 4648 documented the general-purpose Base64 and base64url alphabets in 2006¹.

How encoding works

The algorithm processes input in groups of three bytes — 24 bits total. Those 24 bits split into four 6-bit groups, and each group (a value from 0 to 63) indexes into the Base64 alphabet¹:

• Values 0–25: A through Z
• Values 26–51: a through z
• Values 52–61: 0 through 9
• Value 62: +
• Value 63: /

Plus = for padding.

The complete Base64 alphabet from RFC 4648

The MIME alphabet uses characters represented identically in the referenced ASCII and EBCDIC variants, while excluding characters with special meaning in SMTP⁴.

Encoding the string 'Man' into Base64

Take "Man". ASCII values 77, 97, 110 give us 01001101 01100001 01101110 — 24 bits. Split into four 6-bit chunks: 010011 (19), 010110 (22), 000101 (5), 101110 (46). Look each up: T, W, F, u. So "Man" becomes TWFu.

Padding

When input length isn't a multiple of three, the encoder pads with zeros and appends = characters. Two remaining bytes produce three Base64 characters plus one =. One remaining byte produces two characters plus ==¹.

Padding depends on how many bytes remain in the last group

"Ma" (two bytes) encodes to TWE=. "M" (one byte) encodes to TQ==. Padding completes the final four-character output unit and indicates whether its encoded data came from one or two input bytes. Specifications that define an unpadded profile, such as JWS, recover the final length from the unpadded data.

The 33% overhead

Every complete three-byte block produces four ASCII characters: a ratio of 4/3, or about 33.3% growth⁴. Short inputs can have a larger percentage increase because the final block still uses four characters.

Base16 uses two characters per input byte, while Base32 uses eight characters per five-byte block. Of the Base16, Base32, and Base64 encodings in RFC 4648, Base64 has the lowest character overhead for complete blocks¹.

Where it shows up

Email (MIME) — RFC 2045 specifies Base64 as a Content-Transfer-Encoding and limits encoded lines to 76 characters⁴.

Data URLs — RFC 2397 defines the data: scheme for including data directly in a URL and provides a ;base64 form for non-text-safe bytes⁵.

HTTP Basic authentication — A client joins a user ID, a colon, and a password, then Base64-encodes that sequence for the credentials field⁶. Base64 provides no confidentiality; RFC 7617 therefore warns against using Basic authentication without a secure transport such as TLS.

JSON Web Tokens — JWT represents its parts as URL-safe strings separated by periods⁷. Signed JWTs use the unpadded base64url encoding specified by JWS⁸.

PEM-style certificate files — RFC 7468 describes textual encodings that place Base64 data between BEGIN and END boundaries⁹.

Browser APIs — JavaScript's btoa() converts a binary string to Base64, and atob() converts Base64 back to a binary string. Text containing code points above 0xff must first be converted to bytes, for example with TextEncoder¹⁰.

The URL-safe variant

Standard Base64 uses + and / as characters 62 and 63. Those characters can require special handling in filenames and URLs. RFC 4648 therefore defines base64url, which uses - and _ instead¹. Padding remains part of the general base64url definition unless the referring specification says otherwise; JWS is one specification that omits it⁸.

The bit grouping is unchanged. Only the two alphabet characters differ, with padding governed by the protocol that uses base64url.

Base64 vs. its siblings

RFC 4648 standardizes three related schemes¹:

The three binary-to-text encodings defined in RFC 4648

Base16, commonly called hexadecimal, represents each byte with two characters. Its RFC 4648 alphabet is case-insensitive when decoding.

Base32 uses the letters A–Z and digits 2–7. Its alphabet excludes 0 and 1, which can be confused with the letters O, I, and L¹.

Base64 uses fewer output characters for the same complete input blocks: four for three bytes, compared with eight for five bytes in Base32 and two for one byte in Base16.

Not encryption

Base64 is an encoding, not encryption. It uses no key and provides no confidentiality or integrity. For example, SGVsbG8gV29ybGQ= decodes to Hello World; the encoded form should be treated as plainly recoverable data.

Updated: September 7, 2026