Guide · Data formats
Base64 Encoding Explained
Base64 turns arbitrary binary data into a string of printable ASCII characters. It exists because a great many protocols — email, HTTP headers, JSON, XML, URLs — were designed to carry text and cannot safely carry raw bytes.
The alphabet and the ratio
The standard alphabet is A–Z, a–z, 0–9, + and /. That is 64 symbols, so each character carries exactly 6 bits. Three bytes (24 bits) become four characters. The result is roughly 33% larger than the input, which is the cost of turning binary into text.
Padding
When the input length is not a multiple of three, the final group is padded with = characters:
Man -> TWFu (3 bytes -> 4 chars, no padding) Ma -> TWE= (2 bytes -> 3 chars + 1 pad) M -> TQ== (1 byte -> 2 chars + 2 pads)
Padding is required by the standard but is often optional in practice. Some decoders reject a missing pad, so when in doubt, keep it.
The URL-safe variant
Two characters in the standard alphabet are awkward in URLs: + is decoded as a space in form data, and / collides with path separators. The URL-safe variant (RFC 4648 §5) replaces them with - and _ and usually omits padding. It is used by JWT, by many object storage keys and by most modern token formats.
Passing a standard-Base64 value through a query string without encoding it is a classic source of intermittent authentication failures, because the + silently becomes a space before the server ever sees it.
Unicode: the trap
Base64 operates on bytes, not characters. A JavaScript string containing café must first be encoded to UTF-8 bytes before Base64 is applied, otherwise the output is wrong or throws. Any correct encoder — including ours — performs that conversion for you. If you are implementing Base64 manually, this step is where non-ASCII input will break.
Base64 is not encryption
This is the single most important point in this article. Base64 is a reversible encoding with a published algorithm and no key. Anyone can decode a Base64 string in a fraction of a second. It provides no confidentiality whatsoever.
If you need confidentiality, use authenticated encryption such as AES-GCM or ChaCha20-Poly1305, or libsodium’s secretbox, and manage the key properly. Base64 may then be used to make the ciphertext transportable, but it is the second step, never the security boundary.
Where Base64 genuinely belongs
- Embedding small images or fonts in CSS or HTML data URIs.
- Attachments in email (MIME).
- Binary values inside JSON or XML documents.
- HTTP Basic authentication headers.
- Keys and certificates in configuration files.
Where it does not
- Hiding secrets in a front-end bundle. The value is trivially recoverable.
- Storing passwords. Passwords must be hashed with a memory-hard function, never encoded.
- Compressing data. Base64 increases size; compress first, then encode.
Decoding safely
Treat decoded output as untrusted input. A Base64 blob from a third party can decode to anything at all — a zip bomb, a malformed image, a serialised object. Decode, then validate the type and size before use. Our Base64 tool runs in your browser, so the blob never leaves your machine.