Base64 Explained: What It Is and When to Use It

Base64 is one of those things developers use constantly without necessarily knowing what it's doing under the hood: a way to represent binary data — an image, a PDF, a cryptographic key — as plain, printable text using only 64 characters: A-Z, a-z, 0-9, plus + and / (and = for padding at the end).

Why encode binary data as text at all?

Lots of systems were built to carry text, not arbitrary bytes — early email (SMTP), URLs, JSON, XML, HTTP headers. Raw binary data can contain byte sequences that those formats interpret specially (a null byte, a line-ending sequence, a quote character that breaks JSON) or that simply don't survive transmission intact through older, text-oriented systems. Base64 sidesteps the whole problem: it re-represents any byte sequence using only a safe, portable set of ASCII characters, so it can be embedded directly inside JSON, a URL query parameter, an XML document, or an email body without corruption.

How it actually works

Base64 groups input bytes into chunks of 3 (24 bits) and re-slices those 24 bits into four 6-bit groups, since 2⁶ = 64 — exactly the size of the character set. Each 6-bit group (a number from 0-63) maps to one character in the Base64 alphabet. That's also why Base64-encoded output is always larger than the input: roughly 4 characters of output for every 3 bytes of input, a ~33% size increase. If the input length isn't a multiple of 3, the output is padded with one or two = characters to round out the final group.

Base64 is not encryption

This is the most important thing to understand about Base64, and the most common mistake: encoding is not encryption. Decoding a Base64 string requires no secret, no key, and no password — it's a fixed, publicly known, reversible transformation. Anyone can decode a Base64 string with a single line of code or a tool like this one. If you see a password, API key, or personal data "encoded" in Base64 and stored or transmitted as if that made it secure, that's a real problem — Base64 provides zero confidentiality. Its only job is compatibility with text-based formats, never secrecy.

Where you'll actually run into it

• Data URIs — embedding a small image directly inside HTML or CSS as data:image/png;base64,iVBORw0KG..., avoiding a separate HTTP request.
• Basic HTTP authentication — the Authorization: Basic header carries username:password Base64-encoded (not encrypted — this is only ever safe over HTTPS).
• JWTs — the header and payload of a JSON Web Token are Base64URL-encoded (a URL-safe variant that swaps +// for -/_ and usually drops padding) so a token survives being placed in a URL or header.
• Email attachments — MIME encodes binary attachments as Base64 so they travel safely through mail servers built around 7-bit text.
• Embedding binary in JSON or XML — an API returning a file's contents inline, since JSON strings can't safely contain arbitrary binary bytes.

Try it yourself

Use our Base64 Encoder to convert text or an uploaded file to Base64, or the Base64 Decoder to go the other way — it also previews the result as an image or PDF and understands data: URIs directly. Both run entirely in your browser, so nothing you paste in is ever uploaded anywhere.