What is Base64, and when should you use it?
Base64 is an encoding scheme, not an encryption or compression scheme. It takes arbitrary binary data — an
image, a file, raw bytes — and re-represents it using only 64 printable ASCII characters (A–Z, a–z, 0–9, +, /, and = for padding). The output is
always about 33% larger than the input, because it's trading space efficiency for the guarantee that the result
is plain text.
Why that guarantee matters
A lot of systems — email (MIME attachments), JSON, XML, URLs, HTTP headers — are built to carry text safely, but choke on arbitrary binary bytes (a null byte, an unescaped quote, a byte sequence that isn't valid UTF-8). Base64 sidesteps all of that: since the output only ever uses those 64 safe characters, it can be embedded directly inside a JSON string, a URL query parameter, or a data URI without any further escaping.
Common uses
- Embedding a small image directly in HTML/CSS as a
data:image/png;base64,...URI. - Putting a binary token (like a signed cookie or API key) into an HTTP header or URL.
- Encoding email attachments (this is literally what MIME does under the hood).
- Storing binary data in a system that only accepts text, like some JSON-based config formats.
What it isn't for
Base64 provides zero confidentiality — anyone can decode it back to the original bytes instantly, with no key or password required. It's not encryption, and it shouldn't be used to "hide" sensitive data like passwords or secrets. It's also not compression — the output is larger than the input, not smaller.
The UTF-8 trap
Base64 operates on raw bytes, not characters. If you naively encode a JavaScript string with btoa()
directly, any character outside the Latin-1 range (accented letters, Korean, emoji) throws or gets silently
corrupted, because btoa() expects a "binary string" where every character is a single byte 0–255.
The fix is to convert the text to actual UTF-8 bytes first (via TextEncoder) and Base64-encode that — which is exactly what hexnook's Base64 tool does automatically.