Base64 Encode & Decode

Base64 solves one specific problem: moving binary data through a channel that only reliably carries text. It takes three bytes at a time and re-expresses them as four characters drawn from a 64-character alphabet — A–Z, a–z, 0–9, plus `+` and `/` — with `=` used as padding when the input length is not a multiple of three. That is why Base64 output is always about 33% larger than the input: you are spending four characters to carry three bytes.

It shows up constantly: email attachments (MIME), data URIs that embed an image directly in HTML or CSS, HTTP Basic Authentication headers, the header and payload sections of a JWT, certificates in PEM format, and binary blobs stashed inside JSON.

The most important thing to understand is that Base64 is **not encryption**. It is an encoding, with no key and no secret. Anyone who sees a Base64 string can decode it instantly — this page does exactly that. If you find credentials Base64-encoded in a config file or an HTTP header, treat them as being written in plain text, because in every meaningful sense they are.

The Unicode handling deserves a mention because it trips people up. The browser's built-in `btoa()` only accepts Latin-1 characters and throws on anything else, which is why encoding an emoji or a Hindi string in the console fails. This tool encodes to UTF-8 bytes first and then applies Base64, so any text round-trips faithfully. Decoding reverses that, and if the decoded bytes are not valid UTF-8 — because the input was genuinely binary, like an image — you are told so rather than shown mojibake.

The URL-safe variant (RFC 4648 §5) swaps `+` and `/` for `-` and `_` and drops the padding, because the standard characters have special meaning inside URLs. Decoding here accepts both variants automatically and re-adds any missing padding.