Base64 Encoder / Decoder

Understanding Base64 Encoding

Base64 is a binary-to-text encoding scheme that represents binary data using 64 printable ASCII characters: A-Z, a-z, 0-9, +, and /. It is defined in RFC 4648 and is the standard way to embed binary content in text-based protocols like JSON, XML, HTML, and email.

How the 3-to-4 Byte Mapping Works

The encoder takes input bytes in groups of three (24 bits) and splits them into four 6-bit groups. Each 6-bit value indexes into the Base64 alphabet, producing four output characters. Because 6 bits can represent exactly 64 values (0-63), the mapping is lossless and reversible. When the input length is not a multiple of three, padding with = characters fills the remaining positions — one pad for a 2-byte remainder, two pads for a 1-byte remainder. This padding makes the output length always a multiple of four, which simplifies decoder implementation.

Standard vs URL-safe vs MIME Variants

Standard Base64 (RFC 4648) uses + and / as characters 62 and 63, which are valid in email but problematic in URLs. The URL-safe variant replaces them with - and _, and typically omits padding. This is the format used in JWT (JSON Web Tokens) and OAuth PKCE challenges. MIME Base64 (RFC 2045) is identical to Standard in alphabet but inserts \r\n line breaks every 76 characters to stay within SMTP message length limits. Our tool handles all three: select the variant from the tab bar, and the decoder auto-detects by normalizing characters before processing.

Base64 in Smart Card and EMV Contexts

Base64 appears throughout the smart card ecosystem. PEM-encoded certificates (used in GlobalPlatform secure channel key sets) wrap DER-encoded ASN.1 binary in Base64 between -----BEGIN CERTIFICATE----- markers. EMV key certificates — issuer public key certificates, ICC public key certificates — are binary structures often transported as Base64 in configuration files. APDU command-response logs sometimes encode binary responses as Base64 for readability. The data: URI scheme uses Base64 to inline images and fonts directly in HTML or CSS, avoiding additional HTTP requests.

Decoding Binary vs Text

A common confusion: Base64 can encode any binary data, not just UTF-8 text. When decoding, the result might be a PEM certificate, a JPEG image, or a raw binary protocol message. Our tool uses TextDecoder with fatal: false, so it attempts UTF-8 interpretation and falls back gracefully if the bytes are not valid text. For purely binary inspection (like examining a DER-encoded certificate), decode the Base64 and then paste the resulting hex bytes into the ASN.1 Parser to see the certificate structure.

Base64 vs Hex vs Base32

Hexadecimal encoding doubles the data size (2 characters per byte), while Base64 expands it by roughly 33% (4 characters per 3 bytes). Base32 (RFC 4648) uses 5-bit groups and a 32-character alphabet (A-Z, 2-7), expanding data by about 60% but offering case-insensitive matching and a larger set of unambiguous characters. Base64 is the most compact text-safe encoding and is universally supported. Choose hex when you need human-readable byte values, Base32 when case-insensitivity matters (like secret keys shared over phone), and Base64 for everything else.

Common Pitfalls and Debugging

When a Base64 string fails to decode, check for these issues: truncated input (copy-paste sometimes cuts the last characters) — the length must be a multiple of 4; wrong variant (Standard vs URL-safe) — our decoder normalizes automatically, but other tools may not; embedded whitespace (newlines in PEM files) — strip before decoding; missing padding (JWT tokens often omit =) — the decoder adds it back automatically; and character encoding mismatch — if you encoded as Latin-1 but decode as UTF-8, accented characters will be wrong.