Base64 is a binary-to-text encoding scheme that converts binary data into a sequence of printable ASCII characters. It is one of the most widely used encoding methods in web development, email protocols, cryptography, and data transfer, yet many developers only understand it superficially. This guide explains exactly what Base64 is, why it exists, how it works mathematically, and where you should (and should not) use it.

Why Base64 Exists

Base64 was created to solve a specific problem: not all transport protocols and systems can handle arbitrary binary data. Early email protocols like SMTP were designed to transmit ASCII text only. When the need arose to attach binary files (images, documents, executables) to emails, a way to represent binary data as ASCII text characters was needed. Base64 was standardized in RFC 1421 (1993) to solve this. Today it is used far beyond email — in JWTs, data URIs, API payloads, and embedded assets.

How Base64 Works

Base64 works by taking every 3 bytes of binary input (24 bits) and splitting them into four 6-bit groups. Each 6-bit group maps to one of 64 printable ASCII characters: A-Z (26), a-z (26), 0-9 (10), and + and / (2). The character = is used for padding when the input is not divisible by 3. This 3-byte-to-4-character mapping means Base64 output is always exactly 33% larger than the original binary data — a significant overhead to keep in mind.

Base64 in Data URIs

One of the most common modern uses of Base64 is embedding images and fonts directly into HTML or CSS as data URIs. Instead of an external `<img src="photo.jpg">` that requires an HTTP request, you can embed the image as `<img src="data:image/jpeg;base64,/9j/4AAQ...">`. This eliminates the network round-trip for small images. However, Base64-encoded images are 33% larger than the original files and cannot be cached independently by the browser, making this technique most appropriate for small images below 5KB.

Base64 in JWTs

JSON Web Tokens (JWTs) use Base64url encoding (a variant that replaces + with - and / with _ for URL safety) for their header and payload sections. The header and payload are not encrypted in a standard JWT — they are merely encoded, meaning anyone can decode them. Only the signature is cryptographically protected. This is a common source of security mistakes: developers sometimes store sensitive data in JWT payloads believing it is encrypted, when it is only encoded.

Encoding vs Encryption: A Critical Distinction

Base64 is encoding, not encryption. Encoding is a reversible transformation of data format with no secret key — anyone who knows the encoding scheme can decode the data. Encryption requires a secret key and is designed to prevent unauthorized parties from reading the data. Never use Base64 to "protect" sensitive data. A password like "mysecret" Base64-encoded becomes "bXlzZWNyZXQ=" — trivially reversible by any online tool in milliseconds.

Decoding Base64 with CanvasConvert Pro

CanvasConvert Pro provides a Base64 Image Encoder and Decoder tool that runs entirely in your browser. Paste a Base64 string to get the decoded image, or upload an image to get its Base64 representation. This is useful for debugging API responses, working with embedded assets in CSS, and preparing images for data URIs. All processing is client-side, so even confidential encoded payloads never leave your machine.

Conclusion

Base64 is a fundamental tool in every developer's toolkit — understood properly, it solves real problems in data transport and embedding. The key things to remember: it makes data 33% larger, it is not encryption, and it is ideal for small binary data that needs to travel through text-only channels. For larger files, always prefer direct file transfer over Base64 encoding.