Image to Base64 converter, and Base64 to image decoder

What is an image to Base64 converter?

Base64 is a way of writing binary data using only 64 printable characters, so a sequence of bytes that might otherwise contain unprintable values can be pasted into a text file, a URL, a JSON field, or a CSS declaration without breaking anything. An image to Base64 converter reads the raw bytes of a picture and re-expresses them as that text, and a Base64 image decoder does the reverse: it reads the text back and reconstructs the original bytes as a downloadable file.

The text form is most useful wrapped in a data URI, a self-contained string of the form data:image/png;base64,… that a browser, an email client, or a CSS background-image can treat exactly like a normal image reference, with no separate file request. That is what makes a png to base64 conversion practical for embedding an icon straight into a stylesheet, or for storing a small image inline in a database row or an API response.

This page runs both directions from one interface. Switch the Direction toggle to Image to Base64 to encode a file, or to Base64 to image to decode a data URI or a bare Base64 string back into a picture you can preview and download.

How to convert between images and Base64

1. Choose a direction. Set the Direction toggle to Image to Base64 to encode a file, or to Base64 to image to decode text back into a picture.
2. Supply the input. In Image to Base64 mode, drag a PNG, JPEG, GIF, WebP, BMP, SVG or ICO file (up to 10 MB) onto the drop zone, or click Choose an image. In Base64 to image mode, paste a full data URI or a bare Base64 string into the textarea; the preview and a Download image button appear automatically.
3. Copy or download the result. When encoding, click any of the four outputs — Base64, Data URI, CSS background, or HTML img tag — to copy it, and check the Size panel for the file name, type, original bytes, Base64 character count, overhead and pixel dimensions. When decoding, click Download image to save the file, or Clear to start over.

When to inline an image, and when not to

A data URI is not a separate file the browser can manage on its own terms — it is text sitting inside whatever HTML or CSS file carries it. That has real consequences beyond the byte count. The image cannot be cached independently, so every visit re-downloads it whenever the surrounding file changes, and it gets no benefit from being shared across pages the way a normal image file does once it is in the browser cache.

It also cannot be lazy-loaded or served responsively. There is no loading attribute for a string already sitting in the document, and no srcset picking a smaller version for a phone screen — the full-size data is already there, parsed or not. Embedded inside a CSS file, it is worse still: that CSS is a render-blocking resource, so a large inlined image can delay first paint in a way a separate, parallel image request would not.

None of that is about the encoded size being a third larger, which turns out to matter far less than people assume once compression enters the picture — see the next section. It is about control: an inlined image gives up caching, lazy-loading, responsive selection and paint timing in exchange for saving one network request.

The honest rule of thumb: inline images that are small, static, and needed on every load regardless of viewport — a favicon-sized icon, a one-pixel placeholder gradient, a tiny logo mark. Keep photographs, anything that changes independently of the page, and anything reused across many pages as ordinary image files, so the browser can cache, lazy-load and size them properly.

How much bigger does Base64 actually make a file?

Base64 encodes three bytes at a time as four characters, so the encoded length is exactly 4 times the ceiling of n divided by 3 for n input bytes — true for every length from 0 to 4,000 bytes, checked directly. Three bytes give four characters with no padding; four bytes give eight characters with two = signs; five bytes give eight characters with one = sign. As the input grows, that settles to a fixed 33.33% expansion, which is where the familiar warning that Base64 makes images a third bigger comes from.

That figure describes the decoded text, though, and it is mostly false about what actually crosses the network, because HTTP responses are gzipped. Measuring gzip of a raw PNG against gzip of its Base64 encoding across sizes shows the overhead collapsing fast: +11.3% at 8×8 pixels, +4.2% at 16×16, +1.5% at 32×32, and down to +0.9% from 64×64 through 512×512. On 60,000 bytes of incompressible random data, the same comparison goes from +33.33% before gzip to just +0.97% after it.

The reason is that Base64 output uses exactly 64 distinct symbols, which is precisely 6 bits of information carried in each 8-bit character — measured directly as log2(64) = 6.00 bits. Deflate's Huffman coding stage, the part of gzip that assigns shorter codes to more predictable input, picks up on that redundancy and recovers almost exactly the expansion Base64 introduced.

So over a normal compressed response, inlining an image as Base64 costs roughly 1%, not 33%, for anything from about 64×64 pixels upward — the size argument against data URIs mostly evaporates once gzip is in the picture. Only very small images pay a real penalty, because a compressor's own table overhead dominates a tiny payload before it has enough repetition to exploit. One caveat on precision: the exact figure depends on which Deflate implementation compresses the response, and two of them measured here disagree in the tenths of a percent, so read these as “about one percent”, not as a constant. The real reasons to avoid inlining, covered above, are about caching and loading behaviour, not bytes.

Why is it free?

Every conversion happens in your own browser. Encoding reads the file as raw bytes rather than as text — the browser's btoa function throws on any character above U+00FF, so reading a file as text and encoding it would corrupt binary data, which is why this tool reads bytes directly and encodes them in chunks rather than one call, to avoid overflowing the JavaScript call stack on large files. Decoding works the same way in reverse, identifying PNG, JPEG, GIF, WebP and BMP files from their byte signatures even when no data prefix is present.

Because nothing leaves your device, there is no upload, no account, no watermark and no usage cap. The encoder and decoder were checked against Python's base64 module, part of its standard library, across thousands of random binary inputs and every length, agreeing exactly every time and round-tripping every byte back to the original.