Base64 is the most common byte-to-text encoding
Base64 takes a sequence of raw bytes and re-encodes it as text using a 64-character alphabet — uppercase and lowercase letters, digits 0–9, plus + and / — packing 6 bits into every output character. Like Base32, it isn't a numeral system: converting the hex bytes 48656C6C6F(the ASCII text "Hello") to Base64 gives SGVsbG8=, and there's no arithmetic relationship between that string and the plain numeric value those bytes represent. Base64 exists purely to make arbitrary binary data safe to embed in contexts — text files, JSON, URLs, email — that expect printable text and can't reliably carry raw bytes.
Why 6 bits, and where the padding comes from
Base64 uses 6-bit groups because 2⁶ = 64, matching its alphabet size exactly, the same logic Base32 uses with 5-bit groups and a 32-character alphabet. Because bytes are 8 bits and groups are 6 bits, the two only realign every 24 bits — the least common multiple of 8 and 6 — which is 3 bytes of input to 4 characters of output. That's why Base64 output length grows in multiples of 4 and why single or double leftover bytes get padded with = characters: encoding one byte (0xFF) gives /w== (two padding characters), encoding two bytes (0xFFFF) gives//8= (one padding character), and encoding three bytes (0xFFFFFF) needs no padding at all: ////. The padding tells a decoder exactly how many of the final 6-bit groups were real data versus filler.
Where Base64 shows up
Data URIs embed images or fonts directly inside HTML or CSS as Base64 text (data:image/png;base64,...), avoiding a separate file request at the cost of roughly 33% larger size than the original binary. Email attachments have used Base64 since MIME was standardized in the early 1990s, because SMTP was originally a 7-bit text protocol that couldn't reliably carry raw binary. JSON Web Tokens (JWTs) Base64-encode their header and payload sections so a JSON object can be transmitted as a plain string. Basic HTTP authentication sends credentials as a Base64-encodeduser:password string in an Authorization header (not encrypted — Base64 is an encoding, not a cipher, and is trivially reversible). Binary data stored in databases, config files, or command-line arguments is routinely Base64-encoded for the same underlying reason: it turns arbitrary bytes into plain, transportable ASCII text.
Base64 is encoding, not encryption
A recurring point of confusion is treating Base64 as if it provides confidentiality. It doesn't — Base64 is a reversible, publicly-known transformation with no key, so anyone can decode a Base64 string back to its original bytes without any secret. Seeing credentials or tokens Base64-encoded in a request should never be read as "encrypted" or "hidden"; it only means the data has been made safe to transmit as text, not that it has been protected from being read.
Size overhead and when it matters
Base64 output is always larger than its input — 4 characters of text for every 3 bytes of data, an increase of roughly 33%, plus a small amount of additional overhead if line-wrapping is applied (some older MIME implementations insert a line break every 76 characters). For small payloads like tokens or short identifiers this overhead is negligible, but for embedding large binary assets — a sizable image as a data URI, for example — the size increase is a genuine trade-off against the benefit of avoiding an extra network request, and is why data URIs are generally recommended only for small, frequently-reused assets like icons rather than large images.
Base64 versus Base32
Both encodings solve the same problem with different character-set trade-offs. Base64's larger alphabet packs more bits per character, producing shorter output, but requires case-sensitive, punctuation-tolerant contexts to work safely — exactly the kind of context web protocols and JSON provide, and exactly what DNS labels or spoken/typed 2FA codes don't. That's the practical rule of thumb: reach for Base64 when the destination is a general text or web context that tolerates mixed case and +//characters, and reach for Base32 when the destination is case-insensitive or meant to be read or typed by a person.
URL-safe Base64
Standard Base64's + and / characters both have special meaning inside a URL (space encoding and path separators respectively), which makes plain Base64 awkward to embed directly in a URL without additional escaping. A variant called Base64URL, also defined in RFC 4648, replaces those two characters with - and _, which are safe in URLs and filenames, and often omits padding entirely since the context (a fixed-format token, for instance) already implies the original length. JWTs and many web APIs use Base64URL rather than standard Base64 specifically to avoid needing to percent-encode the output.