Base64 Encoding Internals: Bit Shifting, Padding, and the Data URI Scheme

Early internet protocols like SMTP (email) and HTTP were designed strictly for transmitting ASCII text. If you attempted to send a compiled binary file (like a JPEG image or a ZIP archive) directly over these protocols, routers and mail servers would misinterpret raw binary bytes—like 0x00 (Null) or 0x04 (End of Transmission)—as control characters, destroying the file entirely.

To safely transmit binary data across text-only mediums, engineers needed a way to serialize raw bytes into safe, printable ASCII characters. This is the exact problem Base64 solves.

Standard computer memory operates in 8-bit bytes. Base64 encoding takes exactly 3 bytes (24 bits) of binary data and splits it into 4 chunks of 6 bits.

Because 2 to the power of 6 equals 64, a 6-bit chunk can represent exactly 64 different values. This is why the algorithm is called Base64: it converts base-256 binary (8-bit) into base-64 text (6-bit). As a direct mathematical consequence, Base64 encoding increases the size of the payload by exactly 33%.

Let's look at the word "Car" in ASCII:

• 'C' = 67 = 01000011
• 'a' = 97 = 01100001
• 'r' = 114 = 01110010

Smushed together, we get a 24-bit stream: 010000110110000101110010.

Base64 splits this stream into four 6-bit chunks: 010000 (16), 110110 (54), 000101 (5), 110010 (50). These numeric values are then mapped to the Base64 alphabet table.

The standard RFC 4648 Base64 alphabet is carefully chosen to include only safe, universally printable characters:

• Uppercase letters: A-Z (Values 0-25)
• Lowercase letters: a-z (Values 26-51)
• Numbers: 0-9 (Values 52-61)
• Symbols: + and / (Values 62-63)

Mapping our previous chunks (16, 54, 5, 50) against this alphabet yields: Q, 2, F, y. Thus, the text "Car" becomes "Q2Fy" in Base64.

The 3-to-4 ratio requires the input data to be a multiple of 3 bytes. But files rarely conform to this exact size. If you encode the single letter "A" (1 byte), the encoder is missing 2 bytes to complete the 24-bit block.

To fix this, the encoder pads the missing input bytes with zero-bits to perform the calculation, and then uses the equals sign (=) at the end of the output string to indicate to the decoder how many bytes were fabricated. One = means 1 padding byte was added; two == means 2 padding bytes were added. You will never see three === in valid Base64.

While standard Base64 is safe for email, it is not safe for URLs. The + and / characters hold semantic meaning in web requests (spaces and directory paths). If you place standard Base64 in a query parameter, web servers will break the string.

To solve this, the Base64URL variant was created. It simply replaces the + with a minus sign (-) and the / with an underscore (_). Additionally, Base64URL usually omits the padding = entirely, relying on the decoder to infer padding mathematically. This is the exact encoding used to construct JSON Web Tokens (JWTs).

Base64 is heavily utilized in frontend development to embed small images directly into CSS or HTML files via Data URIs, eliminating HTTP overhead. A Data URI looks like this: data:image/png;base64,iVBORw0KGgo....

While this saves a network request, embedding a massive 2MB image as a 2.6MB Base64 string directly in the DOM will block the main thread during HTML parsing and defeat browser caching mechanisms. Use Data URIs sparingly for tiny icons or placeholders.

Because Base64 is not encryption, it is trivially reversible. Developers often need to inspect Base64 payloads (like SAML assertions or Kubernetes Secrets) to verify configuration data.

Our Base64 Encoder / Decoder processes data purely in the browser. It handles both standard and URL-safe variants, strips invalid whitespaces, and ensures your sensitive binary configuration data never leaves your local machine during inspection.