Skip to content
HexSlate

Image to Base64

No image yet

Drop one on the left. The data URL, the size penalty and whether inlining is worth it all appear here.

Base64 always costs exactly a third

The encoding packs 3 bytes into 4 characters, so the payload is 4/3 of the original plus padding: a 33.3% penalty, every time, before the data:image/png;base64, prefix is counted. That is not an implementation detail you can optimise around. It is the arithmetic of the format, and it is the number every "convert your image to Base64" page mentions and then never follows to its conclusion.

Gzip does not rescue it either, and this is where most advice goes wrong. Text compresses well; Base64 of already-compressed image data barely compresses at all, because the source bytes are close to random. Expect a few percent, not the seventy you get on HTML. Anyone comparing a raw Base64 string against a gzipped binary is making inlining look far better than it is.

When inlining is right, and when it is a mistake

Under about 2 kB, inline it. A small icon, a bullet, a 1px gradient: the saved round trip beats the transfer penalty even over HTTP/2, and an asset that small is not worth a cache entry of its own. A blurred low-quality placeholder that must arrive with the HTML is the clearest case there is.

Past about 10 kB, do not. The inflated bytes are re-sent on every page that embeds them, they cannot be cached separately from the document or stylesheet holding them, and they block that file from streaming while the browser reads past them. A 200 kB photograph as a data URL in your CSS makes the stylesheet 270 kB and render-blocking, which is a worse outcome on every metric than one extra request.

Between the two it depends on where it goes, which is why this page says "measure" rather than picking for you.

Common problems

  • The data URL does not work in CSS. Quote it: url("data:…"). An unquoted data URL containing a comma or a parenthesis ends the url() early, and SVG data URLs are full of both.
  • An SVG data URL is huge. Do not Base64 an SVG. It is text, so percent-encoding it is smaller than Base64 and stays readable and gzippable. Base64 is for binary.
  • The browser blocked it. Top-level navigation to a data: URL has been blocked in every browser since 2017, and a Content Security Policy without data: in img-src blocks it in a page. Neither is a problem with the string.
  • Line breaks in the middle. Some tools wrap Base64 at 76 characters, which is correct for MIME email and wrong inside a data URL. Strip the newlines.

Frequently asked questions

Is my image uploaded?

No. The file is read by the browser's own FileReader and never leaves the tab. Decoding uses fetch on the data URL itself, which is the one case where fetch makes no request at all: a data: URL is resolved from the string already in memory.

How is this different from the developer Base64 tool?

Different question, same encoding. That page is about text and arbitrary files, with URL-safe alphabets and UTF-8 correctness. This one is about whether to inline an image, so it shows the size penalty, the verdict and the paste-ready HTML and CSS forms.

Why is there a size limit here?

8 MB, and it is about rendering rather than encoding. A data URL for an 8 MB file is over 10 million characters, and laying that much text out in a code block is what would freeze the tab, not the encoding itself.

Does encoding change the image?

Not a byte. Base64 is a reversible text representation of the exact file, metadata and all. Check that before you paste one into a public repository: the EXIF, including any GPS coordinates, is still in there. The compressor strips metadata because it re-encodes the pixels; this tool does not, because it does not touch them.