Image to Base64

What Base64 Actually Does

It is an encoding, not compression and not encryption. Base64 rewrites arbitrary bytes using sixty four characters that survive any text channel, which makes the result larger rather than smaller and offers no secrecy whatsoever.

Three bytes become four characters. That ratio is where the roughly thirty three percent overhead comes from, plus a little padding and the data URI prefix. The figure shown above is measured on your actual file rather than assumed.

It exists because some channels are text only. Email bodies, JSON documents, stylesheets and source code cannot carry raw binary, so encoding it as text is the only way to put an image there at all.

Anyone can decode it instantly. Base64 offers no protection, so an image containing something sensitive is no safer inline than it is as a file.

How to Use Both Modes

Encoding takes a file and gives you six ready made forms. Drop an image, paste one from the clipboard or browse for it, and the data URI appears alongside the CSS declaration, the HTML tag, the Markdown reference and a JSON value with the string correctly escaped.

The size panel is the part worth reading. It shows what the file weighs on disk, what it weighs encoded and the percentage difference, and it warns when the file is large enough that inlining is likely to be a mistake.

Decoding accepts a full data URI. Paste one and the image is previewed along with its declared media type and decoded size, then downloaded with a sensible extension. A malformed payload produces a clear message rather than a broken preview.

Anatomy of a Data URI

Four parts, in order. The scheme data:, the media type such as image/png, the encoding marker ;base64 and then a comma followed by the payload.

The media type matters. Browsers trust it to decide how to render the content, so a PNG labelled as JPEG may still display but will confuse anything that inspects it.

Base64 is optional in the specification. Text formats can be embedded directly with percent encoding instead, which for SVG is often smaller than base64.

They work almost everywhere. Data URIs are supported in CSS, in image tags, in favicons and in fetch requests. The notable historical exception was Internet Explorer, which capped their length.

When Inlining Is Worth It

Small, critical images above the fold. A logo or an icon needed for the first paint saves a network round trip, which on a slow mobile connection can be worth more than the extra bytes.

Assets that must travel with a single file. An HTML email, a self contained report, a bookmarklet or an offline document all need everything in one place, and a data URI is the only way to include an image.

Tiny decorative graphics. Gradients, patterns, sprites and one pixel spacers under a couple of kilobytes cost more in request overhead than they do in bytes.

Avoiding a cross origin request. Where fetching an image would trip content policy or cross origin restrictions, inlining sidesteps the problem entirely.

When It Makes Things Slower

Anything past about ten kilobytes. Beyond that, the extra third of size and the loss of separate caching usually outweigh the saved request. The tool warns at that threshold for exactly this reason.

Images inside a stylesheet block rendering. A CSS file is render blocking, so an inlined image delays the whole page rather than loading alongside it. A large data URI in CSS is one of the more effective ways to make a site feel slow.

Anything reused across pages. A separate file is downloaded once and cached for every subsequent page. Inlined, it is re-downloaded with every document that contains it.

HTTP/2 removed most of the original argument. Multiplexing made additional requests far cheaper than they were when inlining became popular, so the case for it is much narrower now than the advice from a decade ago suggests.

SVG Deserves Special Treatment

SVG is already text, so base64 only makes it bigger. Percent encoding the markup directly is typically twenty to thirty percent smaller than the base64 form and remains readable in the stylesheet.

Base64 is still simpler. Percent encoding requires escaping the right characters, and getting it wrong produces an icon that silently fails to render. If you are hand editing, base64 is the safer choice.

An inlined SVG cannot be styled from outside. Once it is a data URI in a background image, CSS cannot reach inside it to change a fill colour. Placing the markup directly in the document keeps that possible.

Caching and Cache Busting

Inlined images have no cache entry of their own. They are cached only as part of whatever file contains them, so changing one byte of the image invalidates the whole document or stylesheet.

That cuts both ways. It removes stale image problems, since the image can never be older than the file around it, at the cost of re-downloading everything when either changes.

For frequently changing images it is the wrong model entirely. A separate file with a hashed name gives you long lived caching and instant invalidation together.

Security and Content Policy

Base64 hides nothing. It is trivially reversible, so treat an inlined image exactly as you would treat the file: anything sensitive in it is visible to anyone who views source.

Content Security Policy often blocks data URIs. A policy that does not list data: in its image source directive will silently refuse to render them, which is a common and confusing cause of missing icons.

SVG data URIs carry more risk than raster ones. SVG can contain scripts, so only inline SVG you control or have inspected, particularly when the source is user supplied.

Common Mistakes to Avoid

Inlining a photograph. Photographs are far past the size where inlining helps, and a hero image as a data URI in CSS delays the entire page.

Forgetting the prefix. Raw base64 without data:image/png;base64,in front of it will not render anywhere. The Base64 only output exists for cases that add their own prefix.

Copying a data URI that has been line wrapped. Some editors insert newlines, which most parsers tolerate and some do not. Copy from the field rather than retyping.

Assuming it saves bandwidth. It always costs about a third more. The saving, when there is one, is a request rather than bytes.

Frequently Asked Questions