Image to Base64

Convert an image to a copyable data URI string, or paste Base64 back to preview the image

Drop an image here to convert to Base64, or

Images are never uploaded — the conversion happens locally.


Image to Base64 (data URI): when to inline, when not to

The structure of a data URI

The conversion result is a data URI, structured as:

data:[media type][;base64],data

ExampleMeaning
data:image/png;base64,iVBORw0...a PNG image
data:image/svg+xml;base64,PHN2Zy...an SVG, base64-encoded
data:image/svg+xml,<svg ...>an SVG using URL encoding (smaller, see below)

It can appear anywhere a URL is accepted: <img src="...">, CSS background-image, a favicon, even as a fetch() argument. The browser treats it as an inlined resource and fires no extra request.

Cost 1 — size grows about 33%

Base64 uses 4 characters to carry 3 bytes, so the encoded size is 4/3 ≈ 133% of the original. A 100 KB image becomes about 133 KB of text.

If the server enables gzip or brotli, the Base64 content inside HTML/CSS compresses by roughly 25%–30% (Base64's alphabet is limited), so the real transfer overhead is below 33% — but it is still larger than sending the binary image directly.

Cost 2 — you lose independent caching

This is the bigger problem, and the easiest to overlook:

External imageInlined data URI
Cache unitthe image file itselfthe whole HTML/CSS document
Change the imageredownload only the imageredownload the entire document containing it
Used on many pagesdownloaded oncestored once per page
Initial requestsone more requestone fewer request

So inlining buys "fewer requests" at the cost of "coarser cache granularity and duplication across pages". Under HTTP/2, multiple requests reuse one connection and transfer concurrently, so the "fewer requests" benefit has shrunk a lot — the main reason inlining is recommended less often today than a decade ago.

Cost 3 — no responsive images

Once inlined there is no separate resource URL, so these capabilities all vanish:

Together these mean: valuable for small above-the-fold icons, a clear regression for content images.

When to inline

ScenarioAdviceReason
icon under about 2–4 KBinlineskipping one request beats the size cost
decorative graphic on one page onlyinlinenot reused by other pages, so no cache-granularity issue
must arrive with the pageinlinee.g. email, offline single-file page
HTML emailinline or external (per client)clients handle images very differently
content, product, blog imagesdo not inlinelarge, need responsive, need CDN optimization
icon reused across pagesdo not inlinecopied into every page, total size doubles
large or background imagesdo not inlinethe 33% size penalty is unacceptable

An extra trick for SVG

SVG is text, so it does not have to be base64 — URL-encoding it (escaping only a few characters like # < >) usually yields a shorter result, because base64 turns 3 bytes into 4 characters while plain text leaves most characters unescaped.

But note: in the URL-encoded form the # must become %23 (otherwise it is read as a fragment identifier), and quotes need handling too. That is the usual cause of "my inlined SVG does not show".

How the tool works

Drag an image in or choose a file to get a copyable data URI; below, paste a Base64 string back to restore and preview the image. When restoring a bare Base64 string (no data: prefix), the tool auto-adds data:image/png;base64, then previews — but this assumes PNG. If the original was JPEG or WebP, the restored image may still display yet carry the wrong MIME type, and the downloaded extension will not match. Keep the full prefix for an exact restore.

The whole conversion runs locally; the image is not uploaded — necessary when handling client assets, internal screenshots or pictures with personal information.

FAQ

Can I paste a bare Base64 string without the data: prefix?

Yes — the tool automatically adds the data: prefix before previewing and downloading.