Exactly how much bigger does it get?

About 33%. Three bytes become four characters, giving a 4/3 ratio, plus a short prefix such as `data:image/png;base64,`. A 100KB image becomes a string of roughly 133KB.

Will search engines index an inlined image?

Assume not, at least for image search — there is no URL to index. If image search traffic matters for a given picture, such as a product shot, keep it as a file and give it an alt attribute.

Is there a size limit?

No hard limit in the spec, but a practical one. The document grows accordingly, and very long strings slow down editors and build tools. Past a few tens of kilobytes, consider a file first.

How do I see what a Base64 string actually contains?

Paste it in and convert it back to an image. It works with or without the `data:image/...` prefix, and this direction also runs entirely in your browser.

When to inline an image as Base64 — and when not to

Base64 turns an image into text so it can live directly inside HTML or CSS. You lose the separate request, but the data grows by roughly 33% and the browser can no longer cache the image on its own. That trade works for icons of a few kilobytes and for places that cannot reference external files — email signatures, single-file documents — and almost never works for photographs.

You have seen markup like `<img src="data:image/png;base64,iVBORw0...">`. Instead of pointing at an image file, the file's contents have been turned into text and pasted into the document. It looks convenient, and used carelessly it makes pages slower.

What you are trading

Base64 represents every three bytes of binary as four characters, so the result is **about 33% larger** than the original. What you buy with that is exactly one thing: the file no longer has to be fetched separately. Whether the trade pays off depends on how big the image is and how often it appears.

	As a separate file	Inlined as Base64
Bytes transferred	Original size	About 1.33x
Requests	One per image	None — it is part of the document
Browser cache	Reused per image	Not possible — re-sent with the document
Document size	Unchanged	Grows by the size of the image
Replacing it	Swap the file	Edit and redeploy the document

You save one request and pay for it in size, caching and maintenance.

Losing the cache is the expensive part

The row that actually hurts is caching. As a file, the browser fetches the image once and reuses it on the next page. Embedded as text, the blob comes down again with every page. Inline your logo and ship twenty pages, and a visitor downloads the same logo twenty times.

Inlining into CSS is subtler. CSS files usually cache well, so the image caches with them — but **nothing renders until the CSS has finished downloading.** Bury a heavy image in your stylesheet and you have delayed first paint.

When it pays off

**Icons of a few kilobytes** — saving a request beats the 33% overhead.
**Places that cannot reference external files** — email signatures, single-file HTML documents, offline reports.
**Somewhere a flash of missing content would show** — tiny background patterns that appear late are noticeable.
**When adding a file to the build is awkward** — a one-line stopgap asset.

When it costs you

**Photographs** — hundreds of kilobytes grow by a third and cannot be cached. A file is nearly always better.
**Anything repeated across pages** — logos and header art are precisely what caching is for.
**Images that change often** — every change means editing and redeploying the document.
**A whole set of icons** — inline SVG or a sprite serves you better.

For small icons, look at SVG first

For simple iconography, inlining the SVG source is usually shorter than Base64-ing a PNG. SVG is already a text format, so there is no 33% penalty, its colour can be driven from CSS, and it stays sharp at any resolution. Base64 earns its place when the artwork cannot be expressed as SVG.

Conversion happens inside your browser, so the image is never uploaded. The reverse direction works in the same place: paste a data URI string back and get the image file, which is handy when you need to see what a blob buried in a log or an API response actually is.