Convert an image to base64

The number nobody shows you

Base64 exists to move binary data through channels that only carry text. It does that by spending four printable characters on every three bytes, because it uses just 64 of the 256 values a byte can hold. The arithmetic is fixed and there is no clever encoder that beats it: the encoded copy is always one third larger than the file, plus a header of twenty-odd characters for the data:image/png;base64, part.

That is the single most useful fact about the conversion, and almost every converter online hides it. You paste in a photo, you get back a wall of text, you copy it, and you find out three days later that the stylesheet nobody wanted to touch is now most of a megabyte. This tool puts the original size, the encoded size and the increase on screen the moment the file lands — before there is anything to copy.

If an SVG needs to become fixed pixels before it is embedded, use SVG to PNG first. That route locks the proportions and blocks external SVG resources before rasterization.

The formats involved

PNG

Full name	Portable Network Graphics
Extension	.png
Format type	Lossless raster image, with alpha
MIME type	image/png

JPG

Full name	Joint Photographic Experts Group
Extension	.jpg, .jpeg
Format type	Lossy raster image
MIME type	image/jpeg

Base64

Full name	Base64 binary-to-text encoding
Extension	— not a file format
Format type	An encoding, RFC 4648. Grows the data by about a third
MIME type	— carried inside another format

When image to base64 is the right call

Inlining a file trades bytes for a request. On a small file that trade is good, because the round trip to fetch a separate image costs more in latency than the extra third costs in transfer. Three cases where it clearly pays:

Small icons and UI ornaments. A one-kilobyte chevron, a checkbox tick, a pattern used as a repeating background. These arrive with the stylesheet that needs them, they never flash in late, and they never produce a stray 404 when a build step moves the assets directory.

Email templates. Many mail clients block linked images by default and display inline ones, so an embedded logo is the difference between a design that arrives and a set of gray boxes. Mail is also the one context where nobody expects caching, so the usual argument against inlining does not apply.

Single-file and offline documents. An HTML report you email to a colleague, a bug reproduction saved to one file, a slide deck exported for a machine with no network. Anything that has to survive being moved around on its own is better off carrying its images inside it.

A loading placeholder is a different job from embedding the original image bytes. The BlurHash generator derives a short perceptual string and a low-detail preview from an image; it does not preserve or reproduce the source file the way this base64 encoder does.

A tab icon looks like a fourth case and is not quite one. It is small enough that the trade would pay, and a data URI in a <link rel="icon"> does work in current browsers — but the icon is also the one asset that older clients, feed readers and bookmarking services still fetch as a file from a fixed path, and those fall back to nothing when there is no file to fetch. PNG to ICO produces that file, with the several square sizes packed into it that a single inlined PNG cannot express.

When it is the wrong call

Above roughly ten kilobytes the trade stops paying, and above fifty it is almost always a mistake. Three reasons, and they compound:

It cannot be cached separately. A normal image file is fetched once and reused across every page and every visit. Inlined, it is part of whatever document contains it, so changing a single line of CSS forces the browser to download every embedded image in that file again.

It blocks rendering. A stylesheet is render-blocking by definition — the browser will not paint until it has parsed the whole thing. A 500 KB photo turned into 667 KB of base64 inside a stylesheet is 667 KB standing between the visitor and the first pixel. As a plain src, that same photo downloads in parallel, can be lazy-loaded, and never delays the text.

It multiplies across pages. The same image referenced from five pages is one file and one download. Inlined into five pages, it is five copies, each a third larger than the original, none of them shared.

If the file is too big to inline but has to be smaller anyway, the answer is compression rather than encoding — compress it to a target size first, and see whether it lands under the threshold. The broader question of what actually shrinks a file is covered in how to reduce file size.

Animated GIFs deserve a warning of their own here, because they are the largest thing anyone routinely tries to inline and the extra third lands inside a document that has to finish parsing before a single pixel appears. Bringing the animation itself under a limit with GIF compression moves the number far more than any encoding decision can, and it is worth doing before you reach for a data URI rather than after.

SVG is the exception worth knowing

SVG is already text, so base64 makes it a third bigger for no reason at all. Percent-encoding an SVG into a data URI usually produces a shorter string than base64 does, and browsers handle it fine. If you paste a percent-encoded data URI into the decoder here it says so rather than reporting an invalid character, because that string is not broken — it is simply not base64.

If the SVG file itself is verbose, optimize the SVG before choosing how to reference it. That removes safe representation-level bytes from the vector source; Base64 only changes how the same bytes are encoded and normally makes them larger.

When the source image is embedded in a webpage and you do not yet have the file or data URI, use the image extractor from website on the open tab first. It separates URLs found in HTML, responsive candidates, CSS backgrounds and inline SVG, then records which image bytes the browser could and could not expose before you choose a download.

Decoding, and what a broken string looks like

The decoder accepts what people actually have: a bare payload, a full data: URI, a string wrapped at 76 characters the way MIME does it, the URL-safe alphabet that uses - and _ in place of + and /, and padding that some encoders leave off entirely. When something genuinely is wrong it says which character, at which position, on which line — a stray quote at position 4,081 is a specific problem with a specific fix, and "invalid base64" is not.

The decoded image is rendered before the download button, deliberately. Half of decoding is confirming that the string you were handed is the image you expected, and a download button with no preview makes you check that in your file manager instead.

All of that assumes the payload is a picture. Plenty of base64 is not: a JSON Web Token, a certificate block, a session cookie, a run of text out of a legacy system. Those want the base64 decoder instead, which asks the question this page never has to — which character encoding wrote the bytes — and shows a hex dump with the guessed file type when the answer turns out to be "none of them".

Nothing is uploaded

Encoding is a few dozen lines of bit-shifting, and it runs in this tab. There is no upload endpoint here to send anything to. That is worth stating plainly for this tool in particular, because the things people base64-encode tend to be signatures, identity documents, and screenshots of internal dashboards — files that are being embedded precisely so they do not have to be hosted anywhere.