When should I inline an image as base64?

When the image is tiny (under ~2 KB), only used once, and the extra HTTP request would be a measurable share of the page weight. Common cases: an SVG icon embedded in a CSS module, a one-off background pattern in an email template, an inline logo for a static documentation page.

When should I NOT inline?

Big images. Anything over ~10 KB is better served as a separate file because (a) the browser can cache it across pages, (b) base64 adds ~33 % overhead, and (c) inline content can't be lazy-loaded. Marketing hero images and product photos are almost never good base64 candidates.

What's the size overhead?

Roughly 4/3 (33 % bigger). 3 bytes of binary become 4 base64 characters. So a 12 KB PNG becomes ~16 KB once encoded. Gzip recovers some of that on the wire but not all.

Image to Base64

Convert an image to a Data URI (base64) with ready-to-paste CSS and HTML snippets - or paste a Data URI to preview the image.

Runs in your browser

Two directions on one tab. Encode: drop an image, get the `data:image/...;base64,...` URI plus ready-to-paste CSS and HTML snippets. Decode: paste a Data URI, preview the image, download it as a regular file. Nothing leaves your browser; the encoded blob lives only in memory.

Drop an image here or click to choose

PNG, JPG, WebP, AVIF, GIF, SVG, BMP

How to use it

Pick the direction
Encode (image → base64) or decode (base64 → image) via the tab switch.
Drop or paste
Encode: drag a PNG / JPG / WebP / SVG. Decode: paste a `data:image/...` Data URI string.
Copy the snippet you need
Three ready snippets: raw Data URI, CSS `background-image: url(...)`, HTML `<img src='...'>`.

What is it?

Base64 is a text encoding for binary data - every 3 bytes become 4 ASCII characters drawn from `A-Za-z0-9+/`. When prefixed with `data:image/png;base64,` (or another MIME type) the result is a Data URI: a self-contained reference to an image that browsers, CSS engines and HTML parsers all dereference inline. The trade-off is a ~33 % size penalty in exchange for skipping the HTTP request.

When to use it

Embedding small SVG icons in a CSS module, including a one-shot background pattern in an HTML email, inlining a logo in a build-time-generated PDF, bundling test fixtures in unit tests, or generating an OG image dynamically and serving it as a Data URI. Anywhere you'd otherwise need an extra HTTP request for a tiny asset.

Common mistakes

Inlining a marketing-hero photo and tanking the HTML's parsing time. Forgetting to URL-encode the `+`, `/` and `=` characters when putting the Data URI inside another URL. Pasting a Data URI without the `data:image/png;base64,` prefix (browsers reject it). And inlining a large asset that the browser could otherwise cache across pages.

FAQ

When should I inline an image as base64?: When the image is tiny (under ~2 KB), only used once, and the extra HTTP request would be a measurable share of the page weight. Common cases: an SVG icon embedded in a CSS module, a one-off background pattern in an email template, an inline logo for a static documentation page.
When should I NOT inline?: Big images. Anything over ~10 KB is better served as a separate file because (a) the browser can cache it across pages, (b) base64 adds ~33 % overhead, and (c) inline content can't be lazy-loaded. Marketing hero images and product photos are almost never good base64 candidates.
What's the size overhead?: Roughly 4/3 (33 % bigger). 3 bytes of binary become 4 base64 characters. So a 12 KB PNG becomes ~16 KB once encoded. Gzip recovers some of that on the wire but not all.

Image Converter

Convert PNG, JPG, WebP and AVIF in your browser - no upload, no signup.

Base64 Encoder / Decoder

Encode and decode Base64 strings (text and files).

Image Resizer

Resize images by pixels or percentage in your browser - no upload.