Base64 decoder and encoder
Choose an alphabet and encode or decode text locally. Use hex for binary data, and compare strict decoding with the documented forgiving mode.
Convert text locally. JavaScript is required; no input is uploaded or stored.
How it works
RFC 4648 maps each group of three bytes to four characters, using six bits per character. UTF-8 encoding happens before Base64; hex mode handles arbitrary bytes. Base64url replaces + and / with - and _.
Strict decoding requires complete padding, the selected alphabet, no whitespace and zero unused trailing bits. Our forgiving mode ignores ASCII spaces, tabs, line feeds, form feeds and carriage returns, accepts missing padding, and discards non-zero trailing bits with a diagnostic. It still rejects malformed padding and invalid characters. This is a named local policy, not a promise to match every decoder.
No rounding occurs. Encoding input and decoded data are limited to 512 KiB; Base64 decoding input allows 699,052 characters, enough to round-trip the maximum encoded output. Invalid UTF-8 leaves text output empty and reports the error; hex remains available. Empty input is valid.
Worked examples
RFC text vector
The UTF-8 bytes for foo are 66 6f 6f. They encode to Zm9v, with no padding.
Padding and binary bytes
f encodes to Zg==. Hex ff encodes to /w==, or _w== in Base64url; ff alone is invalid UTF-8.
Frequently asked questions
Is Base64 encryption?
Can I decode Base64 without padding?
Why is Zh== rejected in strict mode?
Why do I see a UTF-8 error?
Are inputs saved or uploaded?
Sources
- HTML Standard — limiting user input length (checked 2026-11-14)
- RFC 4648 — sections 3–5 and 10 (checked 2026-11-14)
Last reviewed 2026-11-14. The method is written out above so you can check our math.