Skip to content

Image to Base64

Data URL, CSS or raw Base64.

  • Files stay on your device
  • No upload, no waiting
  • No sign-up, no watermark

or drag a file here · never uploaded

All image tools

Questions

Why is the Base64 output bigger than my image?

Base64 represents binary using 64 printable characters, turning every three bytes into four — an inherent 33% increase, plus a little for padding. That overhead is the whole trade-off: it exists so binary can travel through systems designed only for text, such as JSON payloads, HTML attributes, CSS files and email bodies.

When is inlining an image actually worth it?

For very small images, roughly under 2 KB, where the overhead costs less than a separate HTTP request — tiny icons, spacers and placeholders. Also for critical above-the-fold graphics that should render with the HTML rather than after a second round trip, and for single-file deliverables like HTML emails or offline reports.

When is it a mistake?

For anything more than a few kilobytes. Inlined images cannot be cached separately, so the same bytes are re-downloaded with every page that includes them, and they inflate the HTML or CSS that must parse before anything renders. They also cannot be lazy-loaded or served responsively. With HTTP/2 multiplexing, the request-count argument that justified inlining a decade ago is largely gone.

What is the difference between the output formats?

A data URL carries the MIME prefix and goes straight into an src attribute or a CSS url(). Base64 only omits that prefix, which is what an API wants when it has a separate field for the type. The CSS and HTML options wrap the same data URL in a ready-made declaration or element so you can paste it directly.

Why does my inlined image fail after building?

Some older build tools and minifiers mangle very long data URLs in CSS, and a single altered character makes the image silently fail to decode. Test the built output rather than only the development build. Shrinking the source first with the image compressor also helps, since the encoded string shrinks with it.

About image to base64

What Base64 actually is

Base64 encodes arbitrary binary data using 64 printable characters, so a file can travel anywhere text can. Every three bytes become four characters, which is why the encoded result is about 33% larger than the original — plus a little for padding and any line breaks.

That overhead is the whole trade-off. Base64 exists so binary can pass through systems that were only ever designed for text: email bodies, JSON payloads, HTML attributes, CSS files.

When inlining an image is worth it

  • Very small images. Under about 2 KB, the overhead is less than the cost of a separate HTTP request. Tiny icons, spacers and single-colour placeholders are good candidates.
  • Critical above-the-fold graphics. An inlined logo renders with the HTML, with no second round trip. On a slow connection that is a visible difference.
  • Single-file deliverables. An HTML email, a standalone report, an offline document that has to work with no external assets at all.

When it is a mistake

For anything more than a few kilobytes, inlining usually makes the page slower. Inlined images cannot be cached separately, so the same bytes are re-downloaded with every page that includes them, and they inflate the HTML or CSS that must parse before anything renders. They also cannot be lazy-loaded, served responsively, or swapped for a modern format per browser.

With HTTP/2 and HTTP/3 multiplexing requests over a single connection, the request-count argument that justified inlining a decade ago is largely gone. Treat inlining as a targeted optimisation for genuinely small assets, not a default.

Data URL, CSS or raw?

  • Data URLdata:image/png;base64,…. Goes straight into an src or a CSS url(). Use this unless you have a reason not to.
  • Base64 only — no prefix. What an API expects when it has its own field for the MIME type.
  • CSS and HTML — the same data URL, already wrapped in the declaration or element.

One practical warning for CSS: some older build tools and minifiers mangle very long data URLs, and a single mangled character makes the image silently fail to decode. Test after building, not just in development.

Related

Browse the rest of the image tools, or shrink the source first with the image compressor — the encoded string shrinks with it.