Base64 is one of those terms that sounds cryptographic but is not. It is an encoding — a reversible way to represent binary data (like an image) using only 64 safe text characters. Anyone can decode it instantly, so its job is compatibility, not secrecy. Here is where it genuinely helps and where people misuse it.
The problem it solves
Some systems only handle plain text safely — classic email, JSON fields, URLs, HTML attributes. If you try to shove raw binary through them, bytes get mangled. Base64 solves this by mapping every three bytes of binary into four printable characters drawn from A–Z, a–z, 0–9, plus + and /. The result is text that survives any text-only channel intact, and can be decoded back to the exact original bytes.
Why the file gets bigger
There is a cost: because three bytes become four characters, Base64 output is roughly 33% larger than the original. That trade-off — more size for guaranteed text safety — is the whole point. It is why you would never Base64-encode a large video for storage, but happily encode a tiny icon to inline it.
Real, everyday uses
Data URIs: a small logo can live directly inside CSS or HTML as data:image/png;base64,iVBORw0..., saving a network request. Email attachments: MIME uses Base64 so binary files travel through text-based mail servers. JSON payloads: when an API must carry a small binary blob, Base64 lets it ride inside a JSON string. JWT tokens: the parts of a JSON Web Token are Base64url-encoded (more on that in our JWT guide).
The critical misconception
The single most important thing to understand: Base64 is not encryption and offers zero security. Because the transformation is public and reversible, anyone can decode a Base64 string in one second at a site like base64decode.org. Never use it to “hide” passwords, API keys, or personal data — that is a genuine security mistake we still see in code reviews. If you need secrecy, encrypt; if you just need to move binary safely through a text channel, Base64 is exactly the right tool.
Working out the size cost before you commit
The 33% overhead is predictable, so you can budget for it. Base64 turns every three bytes into four characters, then pads the result to a multiple of four with = signs. The formula is straightforward: take your original size in bytes, divide by three, round up, then multiply by four.
A 90 KB logo becomes roughly 120 KB once encoded. A 2 MB photograph becomes about 2.7 MB. That matters most when the encoded data travels on every page load, which is precisely the situation where people reach for Base64 without thinking it through.
When inlining an image is a mistake
Embedding a small icon as a data URI saves an HTTP request, and for a 1 KB icon that trade can be worth it. Embedding a large hero image is usually a poor decision, for three reasons that compound.
First, inlined data cannot be cached separately: the browser re-downloads it with the HTML on every uncached page view, whereas a normal image file would be served from cache after the first visit. Second, inlined data blocks rendering, because the parser must read through it before reaching the content below. Third, Base64 compresses poorly compared with the original binary, so gzip recovers less than you might hope.
The practical rule most teams settle on is to inline only assets below a few kilobytes, and to leave anything larger as a separate cacheable file.
Base64 is not security, and the confusion is dangerous
This deserves stating bluntly because the mistake keeps appearing in real systems. Base64 is reversible by anyone, with no key and no secret. Decoding it takes one line of code or a single visit to any online decoder. Storing a password, an API token or personal data in Base64 and treating it as protected is equivalent to storing it in plain text with extra steps.
The reason people fall for it is that Base64 output looks scrambled to human eyes. That appearance carries no cryptographic weight whatsoever. If you need secrecy you need encryption, which requires a key; if you need to verify integrity you need a hash or a signature. Base64 solves a transport problem, and only that.
Recognising Base64 when you see it
Encoded output draws only from A–Z, a–z, 0–9, plus + and /, and often ends with one or two = characters. A string of that shape whose length is a multiple of four is very likely Base64. One variation worth knowing is URL-safe Base64, which substitutes - and _ for + and / so the value survives being placed in a query string. JSON Web Tokens use exactly this variant, which is why a JWT looks like Base64 but breaks if you decode it with a strict standard decoder.
Common questions
Is Base64 a form of encryption?
No. Base64 is a reversible encoding with no key and no secrecy — anyone can decode it instantly. Never use it to protect sensitive data.
Why is Base64 data larger than the original?
It maps every 3 bytes to 4 text characters, so output is about 33% bigger. That size cost buys guaranteed safe transport through text-only channels.
When should I use a Base64 data URI for images?
For very small images (icons, tiny logos) to save an HTTP request. For larger images, a normal file URL is faster and cache-friendly.
How do I decode a Base64 string?
Use any online decoder, or in a terminal run: echo 'aGVsbG8=' | base64 -d. In JavaScript, atob() decodes and btoa() encodes.