What is the data URI scheme for images?

A data URI embeds resource bytes in the URL itself, e.g. `data:image/png;base64,…`. The MIME type tells the browser how to interpret the payload. It avoids a separate HTTP request but increases HTML/CSS size and bypasses normal cache granularity for that asset.

When should I inline images as Base64?

Reasonable for tiny icons, single-use sprites under a few KB, or emails where external hosting is unreliable. Poor for large photos or assets reused across pages—those should be separate files with cache headers. Always compare encoded length (~4/3 of raw binary) plus surrounding markup to the cost of one cached HTTP request.

What are the performance tradeoffs of Base64 images?

You save a round trip but grow the containing document, so first-byte HTML/CSS parsing can slow. Base64 is not compressed by gzip/brotli as efficiently as binary. Multiple inline images duplicate bytes on every page load unless your HTML is cached as a whole—usually worse than a shared static URL.

Do all modern browsers support image data URIs?

Yes for display in `img src`, CSS `url()`, and Canvas in current evergreen browsers. Very long data URIs can hit URL length limits in some contexts (not typical img src). Content Security Policy may restrict `data:` in styles or scripts—check your CSP if inline images fail silently.

Why is Base64 larger than the original binary file?

Base64 maps 3 bytes to 4 ASCII characters, yielding about a 33% expansion before compression. The payload is text, so it is less compressible than raw image bytes. That is why inlining is reserved for small assets where the request overhead dominates.

Base64 Image Converter

v1.0.0

Convert images to Base64 strings or decode Base64 back into image files with previews, drag & drop upload, and download support.

Upload Image

Click to upload or drag & dropPNG, JPG, GIF, SVG up to 10MB

Base64 Output

Base64 output will appear here

Turn small images into data URIs—or recover files from Base64—for quick prototypes, emails, and embedded assets. Know the 33% size tax before you inline everything.

Read the full guide →

Frequently Asked Questions

What is the data URI scheme for images?: A data URI embeds resource bytes in the URL itself, e.g. `data:image/png;base64,…`. The MIME type tells the browser how to interpret the payload. It avoids a separate HTTP request but increases HTML/CSS size and bypasses normal cache granularity for that asset.
When should I inline images as Base64?: Reasonable for tiny icons, single-use sprites under a few KB, or emails where external hosting is unreliable. Poor for large photos or assets reused across pages—those should be separate files with cache headers. Always compare encoded length (~4/3 of raw binary) plus surrounding markup to the cost of one cached HTTP request.
What are the performance tradeoffs of Base64 images?: You save a round trip but grow the containing document, so first-byte HTML/CSS parsing can slow. Base64 is not compressed by gzip/brotli as efficiently as binary. Multiple inline images duplicate bytes on every page load unless your HTML is cached as a whole—usually worse than a shared static URL.
Do all modern browsers support image data URIs?: Yes for display in `img src`, CSS `url()`, and Canvas in current evergreen browsers. Very long data URIs can hit URL length limits in some contexts (not typical img src). Content Security Policy may restrict `data:` in styles or scripts—check your CSP if inline images fail silently.
Why is Base64 larger than the original binary file?: Base64 maps 3 bytes to 4 ASCII characters, yielding about a 33% expansion before compression. The payload is text, so it is less compressible than raw image bytes. That is why inlining is reserved for small assets where the request overhead dominates.