About

Base64 encoding represents binary data as ASCII text using a 64-character alphabet (A - Z, a - z, 0 - 9, +, /). It inflates payload size by roughly 33% because every 3 input bytes become 4 output characters. Pasting a corrupted Base64 string into a decoder that silently fails produces garbage HTML that breaks rendering or, worse, injects malformed tags into a production page. This tool validates the input character set and padding before decoding, flags illegal sequences explicitly, and renders a live sandboxed preview so you can verify the markup before committing it to your codebase.

Both standard (RFC 4648 §4) and URL-safe (RFC 4648 §5) alphabets are accepted. The converter automatically detects URL-safe characters (- and _) and normalizes them. Note: this tool assumes UTF-8 encoded source HTML. Multi-byte sequences outside UTF-8 may produce replacement characters (U+FFFD).

Formulas

Base64 encoding maps every group of 3 input bytes (24 bits) to 4 output characters (6 bits each). The encoded length is calculated as:

L_out = 4 ⋅ ceil(L_in3)

where L_in = input byte length, L_out = output character count (including padding). The overhead ratio converges to 43 ≈ 1.333 for large inputs.

Decoding reverses this: each Base64 character is mapped to its 6-bit index value. Four characters produce three bytes:

byte₀ = (idx₀ << 2) | (idx₁ >> 4)

byte₁ = ((idx₁ & 0xF) << 4) | (idx₂ >> 2)

byte₂ = ((idx₂ & 0x3) << 6) | idx₃

where idx_n is the 6-bit index of the n-th Base64 character. URL-safe decoding first substitutes - → + and _ → /, then restores missing = padding to make the length divisible by 4.

Reference Data

Base64 Character	Index Value	Binary (6-bit)	Notes
A	0	000000	Uppercase start
Z	25	011001	Uppercase end
a	26	011010	Lowercase start
z	51	110011	Lowercase end
0	52	110100	Digit start
9	61	111101	Digit end
+	62	111110	Standard alphabet
/	63	111111	Standard alphabet
-	62	111110	URL-safe replaces +
_	63	111111	URL-safe replaces /
=	-	-	Padding character
Encoding Overhead Ratios
Input size	Output size	Ratio	Padding
1 byte	4 chars	4:1	2 pad chars
2 bytes	4 chars	2:1	1 pad char
3 bytes	4 chars	1.33:1	0 pad chars
1 KB	1.37 KB	1.37:1	Typical overhead
1 MB	1.37 MB	1.37:1	Linear scaling
Common Base64 Use Cases in HTML
Data URIs	data:image/png;base64,... for inline images
Email (MIME)	HTML email body encoding per RFC 2045
API payloads	JSON fields containing HTML fragments
Obfuscation	Template storage in CMS/database blobs
JWT tokens	URL-safe Base64 in header/payload segments

Frequently Asked Questions

The converter strips whitespace and newlines automatically, as these are common in multi-line encoded blocks. However, characters outside the Base64 alphabet (A-Z, a-z, 0-9, +, /, -, _, =) cause a decoding error. The tool reports the exact invalid character and its position so you can fix the source string. A single illegal character corrupts the entire 4-character block it belongs to.

RFC 4648 defines two alphabets. Standard uses + and / at indices 62-63. URL-safe uses - and _ instead, avoiding characters that have special meaning in URLs. This tool auto-detects URL-safe characters and normalizes them to standard before decoding. It also restores missing = padding, which is often stripped in URL-safe contexts (e.g., JWT tokens).

The decoder converts any Base64 string to its raw byte representation interpreted as UTF-8 text. If the original content is binary (e.g., a PNG image), the output will contain garbled replacement characters (U+FFFD) because binary bytes are not valid UTF-8 sequences. For data URIs like data:image/png;base64,..., strip the prefix before pasting and expect non-readable output. This tool is optimized for text/HTML payloads.

The decoded source code is displayed as plain text inside a

 element, which does not execute scripts. The live preview renders inside a sandboxed iframe with the sandbox attribute restricting script execution, form submission, and navigation. Never paste decoded HTML from untrusted sources directly into a production page without server-side sanitization (e.g., DOMPurify or a CSP policy).

This occurs when the original HTML was encoded in a charset other than UTF-8 (commonly ISO-8859-1 or Windows-1252) but is being decoded as UTF-8. Multi-byte UTF-8 sequences get misinterpreted. The tool assumes UTF-8 encoding. If your source uses a legacy charset, you may need to re-encode the original HTML to UTF-8 before Base64 encoding it.

The tool processes inputs up to approximately 5 MB of Base64 text, which decodes to roughly 3.75 MB of HTML. Beyond this, browser memory constraints may cause performance degradation. The atob() function in most browsers handles strings up to several megabytes. For very large files, consider command-line tools like base64 -d on Unix systems.