Base64 Image Embedder (Image to Data URL)

What is a data URL?

A data URL is a way to embed a file's contents directly into a URL, eliminating the need for a separate HTTP request. The format looks like this:

data:[<MIME-type>][;base64],<encoded-data>

For images, the most common shape is data:image/png;base64,iVBORw0KGgo…— the MIME type followed by the Base64-encoded bytes of the file. Browsers treat these as first-class image sources. You can put them in an img src, a CSS background-image, a Markdown image tag, or anywhere else a URL is accepted.

Data URLs have been supported since the early days of the web (RFC 2397 was published in 1998) and work in every browser, every email client (with some caveats below), and every modern static site generator.

When to use Base64 image embedding

Base64 embedding trades network round-trips for file size. It is the right call in specific circumstances and the wrong call in most others.

Good use cases

• Tiny icons and decorations (under ~2KB) that would otherwise trigger a separate HTTP request. Embedding saves the round-trip at almost no file-size cost
• Inline SVG alternatives: sometimes you need a PNG where an SVG would be ideal but a dependency doesn't allow inline markup. A 1KB PNG as a data URL is a fine compromise
• Self-contained HTML emails: many email clients block remote images for privacy reasons. Embedding small logos as data URLs makes them show up by default (with exceptions — see below)
• Single-file HTML documents: offline reports, portable demos, and "save as one file" exports need every asset inline
• Critical above-the-fold images: the hero logo you want to show before anything else loads. Inline it to eliminate the render-blocking request
• CSS sprites replacement for tiny assets: HTTP/2 and HTTP/3 have made this less critical, but if you have 5 tiny icons each under 500 bytes, embedding saves the cost of 5 requests

Bad use cases

• Any image over ~10KB. Base64 inflates file size by ~33%, and you lose all the caching benefits of a real image file. A 100KB photo becomes 133KB of uncachable HTML bloat
• Images shown on more than one page. Real image files are cached by the browser after the first load; data URLs are not — they're re-parsed from the HTML every time
• High-quality photos. Photography needs WebP/AVIF compression delivered from a CDN. Base64 defeats all of this
• Anything you want to lazy-load. Lazy-loading requires a separate URL the browser can defer. A data URL is already in the HTML — there's nothing to defer

How to use this tool

1. Drop an image into the upload area, or click to browse. PNG, JPG, WebP, GIF, SVG, and AVIF are all accepted
2. The tool reads the file via the browser's FileReader.readAsDataURL()— no upload, no network call, the file never leaves your device
3. The live preview shows what was loaded, along with the file name, MIME type, original size, and encoded size (Base64 is ~33% larger than the raw bytes)
4. Copy the full data URL, or use one of the 3 shortcut snippets (CSS background-image, HTML img tag, Markdown image)
5. If the file is over 100KB, a warning appears: embedding files that large bloats your HTML and is almost always the wrong choice

The 33% overhead explained

Base64 encoding maps every 3 bytes of binary data to 4 ASCII characters. That ratio (4/3 = 1.333) is the theoretical lower bound for any encoding that only uses printable ASCII. You cannot get around it — the math requires at least ~33% bloat.

In practice, data URLs are slightly more expensive than that because you also pay for the data:image/png;base64, prefix (~25 bytes) and any URL-safe escaping your framework might apply. For tiny files (under 500 bytes), the overhead can be 40%+ of the original size. For large files (over 10KB), it approaches the theoretical 33% minimum.

Original:  1,000 bytes
Base64:    1,336 bytes  (+33.6% for the encoding)
Data URL:  1,361 bytes  (+36% total including the prefix)

Caveats by context

CSS

Data URLs work fine in background-image, border-image, list-style-image, and anywhere a URL is accepted. The string must be quoted (either single or double quotes):

.logo {
  background-image: url("data:image/png;base64,iVBORw0KGgo...");
  background-size: contain;
}

Tip: if your build tool is complaining about the length or special characters, wrap the whole URL in single quotes and use double quotes for CSS string delimiters (or vice versa). The +, /, and = characters in Base64 do not need escaping inside a URL.

HTML

Browsers treat data URLs in <img src> exactly like any other image source. They render at the correct size, support alt, loading, and decoding attributes. One exception: loading="lazy" is a no-op for data URLs because there's no separate request to defer.

Markdown

Most Markdown renderers (CommonMark, GFM, MkDocs, MDX, VS Code's preview) support data URLs in image syntax: ![alt](data:image/png;base64,…). The resulting Markdown file becomes large but stays self-contained — useful for portable documentation, exported notes, and offline reports.

Email clients (tread carefully)

Email is a minefield. Gmailblocks most data URLs for "security" reasons (specifically, it blocks them in <img> tags). Outlook and several enterprise mail clients do the same. Data URLs are generally safe in Apple Mail, Thunderbird, and most iOS/Android mail apps.

For broad email compatibility, use attached images with content-ID references (cid:) instead of data URLs. They're older but more reliable.

SVG

SVGs can be embedded as data URLs, but for SVG specifically there's a more efficient alternative: URL-encoded SVG using data:image/svg+xml,…. Because SVG is already text, you can skip Base64 entirely and just URL-encode the angle brackets and quote marks. The result is 20–30% smaller than the Base64 equivalent. For this tool, we output Base64 for consistency, but if file-size matters for an SVG, consider the URL-encoded form manually.

Privacy

This tool uses the browser's native FileReader.readAsDataURL(). The file is read into memory and encoded entirely on your device. Nothing is uploaded, logged, or transmitted — safe for unreleased brand assets, private screenshots, and internal diagrams.

Frequently asked questions

What's the maximum size I can embed?

This tool caps uploads at 10 MB, but browsers themselves have no hard limit — Chrome and Firefox handle data URLs up to ~512 MB in memory, and Safari is similar. The practical limit is much lower: anything over 100 KB noticeably bloats your HTML, and anything over 1 MB breaks every measurable web performance metric. This tool shows a warning at 100 KB.

Can I decode a data URL back to a file?

Not with this tool, no — but it's easy. In the browser console: fetch(dataUrl).then(r => r.blob()).then(b => saveAs(b)). Or right-click the live preview image and "Save image as…". The preview in this tool is itself rendered from the data URL, so saving it gives you back the original file bytes.

Why is the encoded size exactly 33% larger?

Base64 encodes every 3 bytes of input as 4 ASCII characters. 4 ÷ 3 = 1.333, i.e. 33.3% larger. Plus the data:image/...;base64, prefix adds a fixed ~25 bytes. For tiny files, that prefix is a significant percentage; for large files, it disappears into the noise and you converge on exactly 33% overhead.

Do data URLs get cached?

The file the data URL appears in (HTML, CSS, etc.) gets cached as normal, but the data URL itself is not cached separately. This is the key downside: if you use the same image on 10 pages via data URL, the image bytes are duplicated 10 times in the cache. With a real image file, it's cached once and reused. For anything used more than once, use a real file.

Can I use this for video or audio?

Technically yes — data URLs support any MIME type. In practice, audio/video files are way too large for embedding to make sense (tens of megabytes at minimum). Use real file URLs and a proper video player. This tool is image/* only.

What about URL-encoded SVG?

For SVG specifically, data:image/svg+xml, followed by URL-encoded markup is smaller than Base64. This tool outputs Base64 for all formats (for consistency), but if you want the URL-encoded version, paste your SVG markup through the URL Encoder, then prefix it with data:image/svg+xml,.

Is my file sent anywhere?

No. The file is read entirely in your browser via FileReader.readAsDataURL(), encoded locally, and displayed in the preview. There is no upload, no analytics on file contents, no server involvement at any point. Close the tab and everything is gone.