Base64 Alphabet Table

The 64 characters

Base64 reads the input 3 bytes (24 bits) at a time and splits them into four 6-bit numbers. Each number, from 0 to 63, is an index into this table. The order is fixed by RFC 4648: uppercase letters for 0 to 25, lowercase for 26 to 51, digits for 52 to 61, then + and /. The last column is the ASCII code of the character, which is what actually gets stored or sent.

Two ranges are worth memorizing. Every character from A to P (0 to 15) starts with the bits 00, and every character from w to / (48 to 63) starts with 11. That is enough to decode a character in your head when you are checking a prefix by hand. A worked example of the bit splitting is in how Base64 works.

The alphabet order is not ASCII order. In ASCII, + and / come first, then digits, then uppercase, then lowercase. Sorting Base64 strings therefore does not sort the underlying bytes: +A== (the byte F8) sorts before AA== (the byte 00). If you need encoded values that sort like the raw bytes, use base32hex from RFC 4648 or plain hex.

The URL-safe alphabet

+ and / both have special meaning in URLs. + decodes to a space in query strings and form data, and / separates path segments. Base64URL, defined in section 5 of RFC 4648, keeps indexes 0 to 61 and swaps the last two:

Everything else, including the bit layout, is identical, so converting between them is a character replacement plus adding or removing padding. JWTs, many API tokens and file-name-safe identifiers use Base64URL, usually without =. The Base64URL encoder produces it directly. The full comparison is in Base64 vs Base64URL.

The padding character

= (ASCII 0x3D) is not part of the 64-character alphabet and never encodes data. It only fills the last 4-character group when the input length is not a multiple of 3:

• 1 byte left over: 2 data characters plus ==.
• 2 bytes left over: 3 data characters plus =.
• No bytes left over: no padding.

So a padded string always has a length that is a multiple of 4, and you never see ===. Without padding, the length divided by 4 leaves 0, 2 or 3, never 1. The padding guide covers when = may be dropped and how to restore it.

Which characters appear where

A few patterns follow directly from the bit layout. They were checked by brute force over all relevant byte values.

Before == you only see A, Q, g or w. With one byte left over, the second character carries 2 data bits followed by 4 zero bits, so its index is 0, 16, 32 or 48. Before a single =, the third character has 2 zero bits at the end, so it is one of 16 characters: A E I M Q U Y c g k o s w 0 4 8. Anything else in that position means a non-canonical encoding, which strict decoders reject.

Random bytes use all 64 characters equally. Each 6-bit group of random data is uniformly distributed, so encrypted data, keys and compressed files produce a flat character distribution. A skewed distribution is a hint that the data is text or has structure.

ASCII text never puts lowercase g to z, digits, + or / first. The first character of each 4-character group holds the top 6 bits of a byte. For 7-bit ASCII the top bit is 0, so that character is always between A and f (index 0 to 31). In SGVsbG8gd29ybGQh (Hello world!) the group starts are S, b, d and b.

In Base64 of ASCII text, + and / are rare. For bytes below 0x80, + can only appear as the fourth character of a group, when the third byte is > or ~. / can only appear there when that byte is ? or the DEL control character. That is why Hi?> encodes to SGk/Pg== and <b> to PGI+.

Runs of A are zero bytes, runs of / are 0xFF. AAAA is three 00 bytes, //// is three FF bytes. Long stretches of A are typical for sparse binary formats, UTF-16 text (Hello is SABlAGwAbABvAA==) and the length fields at the start of SSH keys. More recognizable patterns are listed in common Base64 prefixes.

Other Base64 alphabets

Several systems kept the idea of 64 characters per 6 bits but chose different characters:

• IMAP replaces / with , because / is a common hierarchy separator in mailbox names. A folder called Entwürfe is stored as Entw&APw-rfe.
• bcrypt moves . and / to the front and keeps letters before digits. Its salts and hashes are Base64 in this alphabet without padding, which is why a standard decoder gives the wrong bytes for them.
• crypt(3) uses ./0-9A-Za-z, which is ASCII order. It also packs bits starting from the least significant end, so even with a translated alphabet a standard decoder will not reproduce the hash bytes.
• uuencode and xxencode predate MIME. The uuencode and xxencode tools read and write both.

For encodings with different alphabet sizes, such as Base32, Base58 and Base85, see Base64 vs hex, Base32, Base58 and Base85. Definitions of the terms used here are in the glossary.

FAQ