Base64 Encoder & Decoder

Base64 is a binary-to-text encoding scheme that represents binary data using a set of 64 printable ASCII characters. The character set consists of A-Z (26 characters), a-z (26 characters), 0-9 (10 characters), plus the + and / symbols, totaling 64 unique values. A padding character = is also used when necessary.

Web development relies on Base64 in several critical scenarios. HTTP headers, email protocols (SMTP/MIME), and JSON payloads are all text-based systems designed to handle printable characters only. When you need to transmit binary data - such as an image, a font file, or a compiled script - through one of these text-only channels, you must first convert it to a safe character representation. Base64 solves this problem reliably. It is also the foundation of the Data URI scheme, which lets developers embed file content directly into HTML and CSS source code.

The encoding process operates at the bit level using a technique called bit shifting and masking. The algorithm reads your input data in groups of 3 bytes (24 bits) at a time. Each 3-byte group is then split into four 6-bit chunks. Because 2 to the power of 6 equals 64, each 6-bit chunk maps exactly to one of the 64 characters in the Base64 alphabet.

For example, the ASCII bytes for the word "Man" are 77, 65, and 110 in decimal, which in binary is 01001101 01000001 01101110. Rearranged into four 6-bit blocks: 010011 010100 000101 101110, these map to decimal values 19, 20, 5, and 46 - which correspond to the Base64 characters T, U, F, u. The result is the Base64 string TWFu. This mathematical transformation is completely reversible, which is what allows perfect decoding back to the original binary data.

The trailing equals signs are padding characters. Because Base64 processes data in 3-byte (24-bit) groups, input data whose total byte count is not a multiple of 3 leaves a remainder. If the last group contains only 1 byte, two padding characters (==) are appended. If the last group contains 2 bytes, one padding character (=) is appended. If the input divides cleanly into groups of 3, no padding is needed.

Padding exists purely to keep the output length a strict multiple of 4 characters. Many parsers and protocols require this fixed-width structure to correctly locate block boundaries. In some modern contexts - particularly URL-safe Base64 variants used in JSON Web Tokens (JWTs) - the padding characters are intentionally stripped and must be re-added before standard decoding. If you ever receive a "Invalid character" or "Incorrect padding" error when decoding, the most common cause is missing, extra, or corrupted padding characters.

The Data URI scheme is a URL format defined in RFC 2397 that allows you to embed file content inline using the syntax: data:[MIME type];base64,[Base64 string]. For instance, a small PNG icon can be embedded directly in an HTML img tag as: <img src="data:image/png;base64,iVBORw0KG...">. Browsers treat this identically to a standard file URL - the image renders perfectly without making any HTTP network request.

Data URIs are best suited for small, frequently used assets - icons under 5-10KB, background textures, inline SVG illustrations, or small loading spinners. Embedding these directly into your stylesheet or HTML eliminates the network round-trip cost for each asset. However, Base64 encoding inflates file size by approximately 33%, so embedding large images is counterproductive. Also, embedded assets cannot be cached independently by the browser, meaning every page load that includes the CSS file re-delivers the embedded image data. The correct strategy is to inline small critical assets and keep large images as separate cached files.

Every 3 bytes of binary input produce exactly 4 Base64 characters. This means Base64 encoding consistently increases data size by approximately 33-37% (the extra percent comes from line-break characters that some implementations insert every 76 characters per MIME standards). For a 1MB image file, the Base64-encoded string will be roughly 1.37MB. This size overhead is the fundamental trade-off you accept when using Base64 - you gain text-safe transmission compatibility at the cost of increased payload size.

Standard Base64 uses the + and / characters, which have special meanings in URLs (+ encodes a space, / is a path separator). When Base64 strings need to be embedded in URLs or URL parameters - such as in JSON Web Tokens or OAuth tokens - a URL-safe Base64 variant is used instead. This variant replaces + with - (hyphen) and / with _ (underscore), and typically omits padding characters. If you attempt to decode a URL-safe Base64 string with a standard decoder, you will encounter errors unless you first swap the characters back and restore the padding.