Image to Base64 & Base64 to Image

What base64 is for, and what it is not

Base64 is an encoding, not a compression. It rewrites binary data using 64 printable characters so it can travel safely inside text: a JSON body, an HTML attribute, a CSS file, an email. The output is always about a third larger than the input, which is the opposite of what people expect from a tool described as a converter. It is genuinely useful in those specific places, and genuinely wasteful as a way of storing or sending an image file.

Why the encoded string is bigger than the file

Every three bytes of binary data become four characters of base64, because 64 possible characters encode six bits each and a byte is eight. That arithmetic is fixed, so a 100 KB image becomes roughly 133 KB of text, before any line breaks or whitespace are added. This is worth knowing precisely because the growth is often a surprise, and because it means base64 can never be used to meet a size limit.

• A 3 byte group becomes 4 characters, always.
• Expect about 33 percent growth, plus any whitespace in the output.
• A data URI also carries a prefix such as image/png;base64 before the data.
• If you need a smaller file, resize or compress it. Base64 will not help.

NoteThe conversion runs in your browser. Nothing is uploaded, which matters for the common case of embedding a private screenshot or document.

Data URIs and the prefix that matters

When you see base64 in HTML, it is usually wrapped in a data URI rather than being raw text. The prefix declares the media type and says the data is base64, and the browser cannot render the image without it. A common mistake is pasting an image into a data URI without declaring whether it is PNG or JPG, which produces something that looks correct and silently fails to load.

• Full form: data:image/png;base64,iVBORw0KGgo...
• The media type must match the actual format of the data.
• The base64, marker is required before the data.
• Keep the whole thing on one line. Whitespace inside a data URI breaks it in some contexts.

Decoding safely, and the limits to know

Decoding reverses the process and is where problems show up. A truncated string produces a partial file, and a string that was never valid base64 produces nothing useful rather than an error message. Very large images are also a practical constraint: the encoded text is a third bigger, and pasting several megabytes of text into an editor is slow or impossible. Decoding what you actually intend to use is a sensible habit.

• A truncated string gives a corrupt or partial image, not a helpful error.
• Check that the data is complete before decoding, especially if it was copied from a terminal.
• Very large images produce unwieldy text. Resize first if the image is big.
• Never decode untrusted base64 expecting it to be safe. It is still data, and a file is only as trustworthy as its type.
• In HTML, use a real file URL when you do not need the inline behaviour.