About

Base64 encoding represents binary data using 64 printable ASCII characters (A - Z, a - z, 0 - 9, +, /) plus = for padding. Every 3 input bytes produce 4 Base64 characters, inflating size by approximately 33%. Malformed padding or illegal characters outside the Base64 alphabet will cause silent data corruption in tolerant parsers. This tool uses strict validation: it rejects input containing characters outside the canonical alphabet and verifies that padding conforms to RFC 4648 §4 before decoding.

Decoding operates through the native atob function, then pipes the resulting binary string through a TextDecoder set to UTF-8 to handle multi-byte sequences correctly. Encoding reverses the path via TextEncoder and btoa. Note: this tool processes text payloads. Binary files encoded as Base64 will decode to their raw byte representation displayed as text, which may appear garbled for non-text formats.

Formulas

Base64 encoding maps every group of 3 octets (24 bits) into 4 sextets (6 bits each). The output length is computed as:

L_out = 4 ⋅ L_in3 (rounded up to nearest integer)

Where L_in = number of input bytes and L_out = number of Base64 characters including padding. When L_in mod 3 ≠ 0, padding characters = are appended:

P = 3 − (L_in mod 3)

Where P = number of = padding characters (0, 1, or 2). Each Base64 digit maps to a 6-bit value via the index table: A = 0, B = 1, …, / = 63. The decoding reversal extracts 6-bit indices, concatenates them into a bit stream, then splits into 8-bit octets to recover the original bytes.

Size ratio: L_outL_in = 43 ≈ 1.333

This means Base64 encoded data is always approximately 33.3% larger than the original binary input.

Reference Data

ASCII Character	Decimal	Hex	Binary	Base64 Index
A	65	0x41	01000001	0
B	66	0x42	01000010	1
Z	90	0x5A	01011010	25
a	97	0x61	01100001	26
z	122	0x7A	01111010	51
0	48	0x30	00110000	52
9	57	0x39	00111001	61
+	43	0x2B	00101011	62
/	47	0x2F	00101111	63
= (pad)	61	0x3D	00111101	Padding
Space	32	0x20	00100000	-
!	33	0x21	00100001	-
~	126	0x7E	01111110	-
DEL	127	0x7F	01111111	-
NUL	0	0x00	00000000	-
TAB	9	0x09	00001001	-
LF	10	0x0A	00001010	-
CR	13	0x0D	00001101	-
@	64	0x40	01000000	-
#	35	0x23	00100011	-

Frequently Asked Questions

Base64 processes input in groups of 3 bytes. When the input length is not divisible by 3, padding characters (=) are added to make the encoded output a multiple of 4 characters. One byte remainder produces "==", two bytes remainder produces "=". If the input is exactly divisible by 3, no padding appears. Per RFC 4648 §3.2, the padding ensures decoders can unambiguously determine the original byte count.

This tool automatically strips all whitespace, newlines (LF, CR), and tab characters before decoding. Many systems (e.g., MIME email, PEM certificates) insert line breaks every 76 characters per RFC 2045. The stripping is applied before validation, so pasted multi-line Base64 blocks decode correctly.

Yes. The encoder uses TextEncoder to convert the input string to UTF-8 bytes before applying btoa(). The decoder reverses this by passing the binary string through TextDecoder set to UTF-8. This correctly handles multi-byte sequences including emoji (up to 4 bytes per codepoint), CJK characters, and any Unicode text. Pure atob() alone would fail on multi-byte characters.

Standard Base64 (RFC 4648 §4) uses "+" and "/" as indices 62 and 63. URL-safe Base64 (RFC 4648 §5) replaces these with "-" and "_" to avoid conflicts with URL reserved characters. This tool supports standard Base64. If you have URL-safe input, manually replace "-" with "+" and "_" with "/" before decoding.

The tool warns at inputs exceeding 5 MB of text. JavaScript strings in modern browsers can hold hundreds of megabytes, but the DOM rendering of very large outputs may cause noticeable lag. For inputs under 1 MB, conversion is effectively instantaneous. The atob()/btoa() native functions are implemented in C++ within the browser engine, so the encoding/decoding step itself is fast.

If the original data was a binary file (image, PDF, ZIP), decoding it to text will show raw byte values as characters, which appear garbled. This tool is designed for text-to-text conversion. Binary file payloads decoded here will not render correctly as text. Additionally, if the source was encoded with a different character set (e.g., ISO-8859-1 instead of UTF-8), mismatched decoding will produce mojibake.