Base64 Encoder / Decoder

How it works

RFC 4648 defines Base64 as an encoding that maps arbitrary sequences of bytes onto a 64-character alphabet made of A-Z, a-z, 0-9, plus the two symbols + and /, with = reserved for padding. The encoder reads the input in 24-bit groups, splits each group into four 6-bit values, and looks each value up in the alphabet table. Because three bytes hold exactly 24 bits, every three input bytes become four output characters, and a partial final group is completed with = so the encoded length is always a multiple of four. The purpose is simple: turn binary data into plain text that any ASCII-only channel can carry without corruption.

That guarantee costs size. The output is always one third longer than the input.

The subtle part of Base64 in the browser is Unicode. As MDN documents, btoa() accepts a binary string and throws an exception when any character falls outside the Latin-1 range, which is why pasting Chinese, emoji, or accented letters into a naive encoder fails outright. This tool converts your text to UTF-8 bytes with TextEncoder, maps each byte onto a single character code, and only then calls btoa(). Decoding reverses the pipeline: atob() recovers the byte string and TextDecoder restores the original UTF-8 text, so non-ASCII input round-trips losslessly in both directions.

The four APIs are consistently available across browsers. MDN documents TextEncoder, TextDecoder, btoa, and atob as long-standing web platform features, and the only difference that affects this tool is the documented Latin-1 restriction on btoa(). Since this tool normalizes text to UTF-8 bytes before encoding, the result is deterministic: the same input always produces the same characters, and decoding a valid string reproduces the same bytes in any engine. Nothing in the pipeline depends on a particular rendering engine or version, which keeps results stable when you move data between this page, a server, or another tool.

Boundary cases follow the same rules. Empty input produces valid empty output, and missing = padding is rejected rather than silently repaired.

Use cases

A common use is embedding small images directly in HTML or CSS as data URIs, written data:image/png;base64,.... The HTML standard defines the data URL format, and because the payload is plain ASCII, the browser reads it without an extra request. The same property makes Base64 convenient inside JSON: every alphabet character is printable ASCII, so an encoded payload needs no escaping inside a JSON string, and the JSON grammar in RFC 8259 accepts those characters as-is. That pattern lets you store binary content alongside normal fields in a single document.

HTTP Basic authentication builds on the same idea. A username and password joined with a colon are Base64-encoded into the Authorization header.

Base64 is not the only byte-to-text encoding. RFC 4648 also defines Base32 and Base16 (hex), and the choice depends on the channel. Hex is readable and safe in URLs but doubles the size. Base32 uses only uppercase letters and digits, friendlier for manual entry but larger. Base64 stays the most compact of the three, and base64url adapts it for URLs and filenames by swapping + and / for - and _ and dropping the padding. For secret material, turn to the Web Crypto API for real encryption. Any claim that Base64 encodes for security is a misunderstanding.

Whatever the channel, remember the boundary. Anyone can decode Base64.

Troubleshooting

• “Invalid Base64 input”: remove spaces, newlines, or quotes, and restore any missing = padding.
• Mojibake after decoding: the source was probably encoded in Latin-1 or another charset, not UTF-8. Re-encode the original with a UTF-8-aware tool.
• Missing = padding: URL-safe Base64url drops the padding and swaps + / for - _.
• Empty result: a valid Base64 string can decode to zero bytes, so an empty output is not always an error.
• Input wrapped across lines: some producers wrap long output into fixed-width lines. Strip the line breaks before decoding, since strict decoders reject whitespace.
• + or / inside a URL: in a query string, + decodes as a space. Use the base64url variant or percent-encode the payload.