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 Online

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.

Try it now: Open the free Base64 Image Converter Online tool — no sign-up required.

How Base64 encoding maps bytes to transport-safe text

Base64 uses a 64-character alphabet (A–Z, a–z, 0–9, +, /) plus padding = so arbitrary binary can travel through JSON, XML, and URL-ish contexts that are not 8-bit clean. For images, the interesting part is not the algorithm but the consumption site: browsers decode the string back to bytes and pass them to the image decoder. The same bytes as a .png on disk decode identically when embedded—only packaging and caching behavior change. For arbitrary text and byte streams outside images, the general Base64 Encoder workflow is the parallel path.

Data URIs in HTML, CSS, and bundlers

In HTML, <img src="data:image/webp;base64,..."> works immediately with no network tab entry for the image itself—only for the document. In CSS, background-image: url("data:...") inlines decoration with the stylesheet. Bundlers such as webpack often inline files below a byte threshold using the same mechanism; thresholds exist because pasting megabytes into JavaScript bundles destroys parse time and invalidates whole-chunk caching when any asset changes. When you need a human-readable preview of SVG markup instead of raster bytes, SVG Viewer complements this workflow.

When inlining wins vs when it loses

Inlining wins when the image is tiny, used once, and eliminating a request removes latency on cold loads—think micro-icons in a single HTML email, a demo that must be one self-contained file, or a critical path icon where DNS/TLS would dominate transfer. It loses when the asset is large, shared across routes, or versioned independently: separate URLs get Cache-Control, ETags, and CDN edge caching. After encoding, if the string dwarfs a few kilobytes, export a file and run it through Image Resizer to shrink dimensions and re-evaluate format before reconsidering inline.

CSS backgrounds, sprites, and maintenance cost

Data URIs in stylesheets couple bytes to CSS cache keys: changing one icon can bust a large stylesheet’s hash even if unrelated rules are untouched. Traditional sprite sheets or icon fonts trade different problems; modern icon systems often use SVG symbols or a small set of HTTP-cached files. If you embed repeated icons as Base64 in utility classes, you duplicate identical strings—grep your bundle; the waste adds up. Prefer one shared class referencing a single external URL unless your critical CSS strategy explicitly mandates inline everything for first paint.

Security and hygiene

Never trust decoded binary from untrusted users without scanning and sandboxing—Base64 is obfuscation, not integrity or safety. CSP img-src and default-src may need data: if you rely on inline images; tightening CSP while using many data URIs causes silent failures in production. For production sites, prefer hashed filenames on disk and long-cache headers; reserve data URIs for exceptions you can list on one hand. Decoding unknown Base64 in server-side PDF or image pipelines has been a vector when downstream decoders mishandle polyglot files—treat inbound data like any upload.

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.

Ready to try it yourself?

Use Base64 Image Converter Online for Free