About

Base64 encoding inflates data by approximately 33% - every 3 bytes of source data become 4 ASCII characters. Reversing this to raw binary exposes the actual bit-level structure: authentication tokens, cryptographic hashes, embedded images, serialized protocol buffers. Misinterpreting padding (= characters) or confusing standard Base64 (RFC 4648 §4) with URL-safe Base64 (RFC 4648 §5, using - and _ instead of + and /) corrupts output silently. This tool decodes any valid Base64 input into its binary octet representation, displays conversion statistics, and flags malformed input before damage propagates downstream.

Limitations: this tool operates on UTF-8 compatible byte streams. Binary output represents raw decoded bytes, not the original file structure. For multi-byte Unicode characters encoded via Base64, each decoded byte is rendered as an independent 8-bit group. Maximum input size is 5MB of Base64 text to prevent browser memory issues.

Formulas

Each Base64 character maps to a 6-bit value. Four Base64 characters encode exactly 3 bytes (24 bits) of binary data:

B_bytes = 34 × N_chars

where N_chars = number of non-padding Base64 characters. Each decoded byte b is converted to binary via:

bin_i = padStart(b_i.toString(2), 8, 0)

The total bit count of decoded data:

bits_total = B_bytes × 8

Base64 encoding overhead ratio:

overhead = N_b64B_bytes ≈ 1.333

where N_b64 = total Base64 string length (including padding), and B_bytes = decoded byte count. Padding characters (=) compensate when source byte count is not divisible by 3: 1 remaining byte produces 2 Base64 chars + 2 pads; 2 remaining bytes produce 3 chars + 1 pad.

Reference Data

Base64 Character	Index (Decimal)	Binary Value (6-bit)
A	0	000000
B	1	000001
C	2	000010
M	12	001100
Z	25	011001
a	26	011010
m	38	100110
z	51	110011
0	52	110100
9	61	111101
+	62	111110
/	63	111111
= (pad)	-	Padding indicator
- (URL-safe)	62	111110
_ (URL-safe)	63	111111

Frequently Asked Questions

Standard Base64 (RFC 4648 §4) uses + and / as index 62 and 63 characters. URL-safe Base64 (RFC 4648 §5) replaces these with - and _ to avoid conflicts in URLs and filenames. This converter auto-detects and handles both variants. Mixing the two alphabets in a single string is invalid and will trigger an error.

Padding characters (=) align the Base64 string length to a multiple of 4. They carry no data. A string ending in 1 pad (=) means the last group encoded 2 bytes; 2 pads mean 1 byte. The converter strips padding before computing binary output, so the binary representation reflects only actual data bytes.

Many systems insert line breaks (MIME standard uses CRLF every 76 characters). This converter strips all whitespace (spaces, tabs, CR, LF) before decoding. However, non-Base64 characters other than whitespace are flagged as invalid.

The binary shown is the raw byte representation. To reconstruct a file, you would need to convert each 8-bit group back to a byte and write it as a binary blob. This converter provides a .bin file download that contains the actual decoded bytes, which can be renamed to the correct extension (.png, .pdf, etc.) if you know the original format.

Inputs up to 5MB of Base64 text (approximately 3.75MB decoded) are supported. Beyond this, browser memory constraints may cause slowdowns. The converter displays a progress indicator during processing and warns if the input exceeds the limit.

Some converters display the minimal binary representation (e.g., 110 instead of 00000110). This tool always outputs full 8-bit octets because each decoded byte occupies exactly 8 bits. Truncating leading zeros loses positional information critical for protocols, checksums, and binary file reconstruction.