What Base64 is, and what it isn't
Base64 is a binary-to-text encoding scheme that represents any sequence of bytes as a string of printable ASCII characters. It is defined in RFC 4648, which consolidated several earlier variants (RFC 3548, RFC 1421) into a single standard. The alphabet uses 64 characters: uppercase A through Z, lowercase a through z, the digits 0 through 9, and two additional symbols, plus and slash. An equals sign is used for padding at the end. The point of the scheme is to take binary data that cannot safely pass through systems designed for text, and translate it into a form that can.
It is critical to understand what Base64 is not. It is not encryption. It is not compression. It is not a hash. Anyone can decode a Base64 string in a single line of code with no key, and the output is always larger than the input, never smaller. If you have ever base64-encoded a password or an API key and felt safer, you have been deceived by the visual opacity of the output. Base64 protects data from transport corruption, not from adversarial readers.
The relationship to similar schemes is worth getting straight. Base32 uses a 32-character alphabet of uppercase letters and digits 2 through 7, which is more verbose but case-insensitive and easier to read aloud. Base16 is the formal name for hexadecimal, using only 16 characters. Base85 (also called Ascii85) uses an 85-character alphabet and is denser than Base64, at the cost of using characters that some systems mangle. Each one solves the same problem with different tradeoffs.
The encoding algorithm step by step
The algorithm is straightforward. Take the input bytes and arrange them as a sequence of bits. Group those bits into 6-bit chunks (because 2 to the 6th is 64). Map each 6-bit value to one character in the 64-character alphabet. If the final group has fewer than 6 bits, pad with zero bits to complete it. If the input length is not a multiple of 3 bytes, append one or two equals signs to make the output length a multiple of 4 characters.
The 3-to-4 ratio is the heart of the scheme. Three input bytes equal 24 bits, which split exactly into four 6-bit chunks. This is why every 3 bytes of input become 4 characters of output, a 33 percent size increase. A 1,500-byte file becomes 2,000 Base64 characters. A 1-byte input becomes 2 characters plus 2 padding equals signs (4 characters total). A 2-byte input becomes 3 characters plus 1 padding equals sign (4 characters total).
Padding makes it possible to decode unambiguously. Without the equals signs, you could not tell whether a final 4-character block represented 1, 2, or 3 bytes of input. Some variants omit the padding (the unpadded form used in URLs and JWTs) and instead infer the length from the total character count modulo 4. The decoder simply drops the extra bits at the end. This works but makes the encoding slightly less self-describing.
Where Base64 actually belongs
Base64 was designed for email transport. Early SMTP servers, defined in RFC 821 in 1982, only handled 7-bit ASCII and would corrupt any byte with the high bit set. Binary attachments — images, executables, encrypted files — could not pass through. The MIME standard, published as RFC 2045 in 1996, introduced Base64 as the way to encode binary attachments into 7-bit-safe text. Email still uses this today, although most modern mail servers support 8-bit transport.
The second canonical use is embedding binary assets inside text-based formats. HTML, CSS, JavaScript, JSON, XML, and YAML are all text formats that cannot contain raw bytes. A small image embedded directly in a CSS file as a data URL (data:image/png;base64,...) saves a network round-trip and avoids a separate cached file. JWTs (JSON Web Tokens) use Base64URL to encode the header and payload as URL-safe strings. PEM-encoded certificates and keys use Base64 wrapped in BEGIN CERTIFICATE markers, defined in RFC 7468.
The third use is in URLs and query strings, where many characters are reserved. The Base64 alphabet includes plus and slash, both of which have special meaning in URLs, so the URL-safe variant defined in RFC 4648 replaces plus with hyphen and slash with underscore, and typically omits padding. This variant is what you see in JWTs, in opaque OAuth tokens, and in most modern APIs that need to pass binary data in a URL.
Where it's the wrong tool
Base64 is the wrong tool when you actually need to keep data secret. Encoding is not encryption. If you base64-encode an API key and ship it in a client-side JavaScript bundle, anyone who opens the browser devtools sees the key. The same goes for obfuscating passwords in configuration files: anyone with read access to the file has the password. Use real encryption (AES-GCM with a key stored in a secret manager) or, better, move the credential to a server the client never sees.
Base64 is the wrong tool when the goal is compression. Because the encoding expands data by 33 percent, applying it to a payload that will then be gzipped is a net loss in most cases. Modern HTTP servers gzip responses automatically; if you embed a 1 MB image as Base64 in an HTML page, the page source is 1.33 MB, and even after gzip the size is typically larger than serving the image as a separate file with content negotiation. For images above a few kilobytes, serve them as binary assets.
Base64 is the wrong tool when you need to handle very large data in memory. Decoding a 1 GB Base64 string requires allocating a 750 MB byte array, plus the original string in memory, plus any intermediate buffers. In a JavaScript runtime this can hit memory limits and crash the process. For large payloads, stream the decoding through a transform rather than loading it all at once.
The URL-safe variant and other flavors
The standard Base64 alphabet (A-Za-z0-9+/) is fine for most text contexts but causes problems in URLs and filenames. The plus sign becomes a space when decoded by some URL parsers, the slash is a path separator, and the equals sign is a query parameter delimiter. RFC 4648 defines a URL-safe variant that substitutes hyphen for plus and underscore for slash. JWTs use this variant exclusively, and most modern token formats follow the same convention.
A second variant, called Base64URL without padding, omits the trailing equals signs entirely. This works because the decoder can infer the missing padding from the length of the input modulo 4. The result is shorter and cleaner in URLs, at the cost of slightly more careful decoder logic. Most modern JWT libraries handle this transparently.
A third historical variant is the PEM encoding used for cryptographic keys and certificates, which wraps Base64 text in header and footer lines and inserts a newline every 64 characters. The line wrapping is a relic of older terminal software that could not handle long lines, but it persists in the standards (RFC 7468) for backward compatibility. If you generate a key with OpenSSL, you get PEM by default.
Detecting and validating Base64
Detecting whether an arbitrary string is Base64 is harder than it looks. The valid character set is well-defined (the 64 alphabet characters plus optional equals padding), but many strings of other formats happen to use only those characters. A 32-character hex string (lowercase a-f and digits) is also valid Base64, and decodes to 24 bytes of garbage. A long UUID with hyphens removed is also valid Base64. The validation question is not is this valid Base64 but is this meant to be Base64.
For most practical purposes, you should rely on context rather than detection. If the data came from a field labeled base64 in an API response, treat it as Base64. If it came from a data URL, the encoding is declared explicitly. If you are guessing, look for the padding equals signs at the end (a strong signal that the data is Base64), check that the length is a multiple of 4, and check that decoding produces sensible output (printable text, valid JSON, a known file signature). Libraries like Python's base64 module include a validate option that rejects strings with non-alphabet characters, but they cannot tell you whether the decoded bytes are meaningful.
A related trap is double-encoding. If a system Base64-encodes data that was already Base64-encoded, you get a string that is itself valid Base64 but decodes to another Base64 string rather than to the original data. This happens surprisingly often when data passes through several layers of API gateway, queue, and storage. The fix is to track whether data has been decoded already, not to keep decoding until the output looks reasonable, which can both under-decode (leaving Base64 in the output) and over-decode (corrupting binary data that happens to look like valid Base64).
Performance and size tradeoffs
The 33 percent size overhead is the headline cost. A 100 MB file becomes 133 MB of Base64 text. Over a network with gzip compression enabled, the on-the-wire size often shrinks back close to the original binary size, because Base64 of random data has a predictable structure that gzip exploits. For text-like inputs (where many bytes are ASCII), the gzip savings are even larger. This is why serving Base64 images inline is sometimes acceptable on HTTP/2 connections with compression.
CPU cost is the second concern. Encoding and decoding are simple — a few table lookups per byte — but on very large inputs the constant factors add up. Modern processors include instructions (like AVX2 on x86) that parallelize Base64 operations by a factor of 10 or more, and good libraries use them. If you are decoding megabytes of Base64 in a hot path, pick a library that uses SIMD; in Node.js, Buffer.from(str, 'base64') is already fast.
The final tradeoff is debuggability. A Base64 string looks like noise to a human reading a config file or a network log. If you need operators to inspect values by eye, prefer a text-friendly encoding like hex for short binary values, or store the binary separately and reference it by name. Base64 is a transport encoding, not a display format. Treat it as plumbing.