Turn an image into a Base64-encoded data URI string you can paste into HTML, CSS, or code—generated directly in your browser.
Upload an image to see the encoded output here.
data:image/png;base64,…, paste-ready into <img src> or CSS), Raw base64 string (no data: prefix, for JSON payloads or your own template), <img> tag (full HTML element with alt), CSS background-image (background-image: url("data:…");), or Markdown image link ()..md file. Need to go the other way? Use Base64 Decoder to turn a string back into a downloadable image.Base64 turns binary image bytes into a 64-character ASCII alphabet so they can travel inside text-only contexts — HTML, CSS, JSON, JWT claims, MIME email parts, YAML configs. The cost is roughly +33% bulk and the loss of independent browser caching; the win is one fewer HTTP request and zero cross-origin/CDN dependency. Use it deliberately for small assets, not as a default for every image.
<img src="cid:…"> and external images get blocked until the reader clicks "Display images below". Inlining sub-100 KB hero artwork as base64 sidesteps that — at the cost of a heavier message body./assets/ folder to deploy.multipart/form-data alternatives work the same way.data: URI pasted into a <img> tag.The data: URI prefix tells the browser which decoder to use. Pick the wrong MIME type and the image renders as a broken icon or, for SVG, gets sniffed as XML and may fail Content-Security-Policy checks.
| Image format | Data URI prefix | Notes |
|---|---|---|
| PNG | data:image/png;base64, |
Lossless; ideal candidate when transparency matters |
| JPEG | data:image/jpeg;base64, |
Photos; base64 fights gzip because the body is already entropy-coded |
| GIF | data:image/gif;base64, |
Animation preserved; consider WebP/AVIF for size |
| WebP | data:image/webp;base64, |
Supported in all modern browsers; 25-35% smaller than PNG/JPEG |
| AVIF | data:image/avif;base64, |
Newest, smallest; Chrome 85+, Firefox 93+, Safari 16.4+ |
| SVG | data:image/svg+xml;base64, |
Text format — URL-encoding is usually smaller than base64 (see FAQ) |
| ICO | data:image/x-icon;base64, |
Used for favicons; rarely worth inlining |
| Scenario | Inline as base64? | Why |
|---|---|---|
| 200-byte CSS checkmark used 50× per page | Yes | Saves a request; size penalty is negligible |
| Hero image 80 KB on a marketing page | No | Blocks render via HTML/CSS bloat, defeats browser cache, no HTTP/2 win |
| Single email blast with one banner | Yes | Email clients block external images by default |
| 5 KB SVG logo | Maybe — but URL-encode, don't base64 | Gzip compresses the XML far better than base64 gibberish |
| Avatar in JSON API response | Yes | JSON is text-only; base64 is the standard binary-in-text encoding |
| Image referenced from 10 pages | No | External file is cached once and reused across all 10 |
| Service-worker-cached PWA shell icon | Yes | Inline survives offline / cold-cache; external file may fail |
Base64 maps every 3 bytes of input to 4 ASCII characters drawn from A–Z a–z 0–9 + /, plus = padding. That ratio is fixed by RFC 4648 — there is no way to make it smaller without switching encodings (base85/Ascii85 is ~25% overhead but isn't natively supported by browsers). The tool reports the exact percentage next to the file size; on already-compressed formats like JPEG, gzip won't recover much of that overhead because the underlying bytes are high-entropy.
<img> tag?When the image is small (rule of thumb: under 1-2 KB), used on a single page, and the request would have been an extra round-trip on a cold connection. DebugBear's testing shows the breakeven moves down on HTTP/2 and HTTP/3 because request multiplexing makes individual requests nearly free. For anything above ~5 KB, an external file with a long Cache-Control: max-age will beat inline base64 across repeated visits.
Usually no — URL-encode them instead. SVG is plain XML, which gzips well because the tags and attributes repeat. Base64-encoding scrambles that repetition into pseudo-random characters and removes most of the compressibility, so the same SVG can be 20-30% smaller over the wire as data:image/svg+xml;utf8,<svg…> than as data:image/svg+xml;base64,…. Chris Coyier's "Probably Don't Base64 SVG" walks through the gzip numbers.
data: URI work inside a strict Content-Security-Policy?Only if your CSP explicitly allows it. A policy like img-src 'self' will block every data: image because data: is its own scheme. To permit them you need img-src 'self' data: (and for inline CSS background-image: url(data:…) you also need the style-src directive to allow it). Adding data: widens your attack surface slightly — MDN's CSP reference treats it as an explicit opt-in for that reason.
Yes — that's the main argument against it for anything non-trivial. An external logo.png is fetched once, cached by the browser (and by intermediate CDNs/proxies), and reused across every page that references it. A base64 logo inlined into the HTML must be re-downloaded inside every HTML response, and inlined into a CSS file is cached only as long as that CSS file is. For repeat visitors and multi-page sites, separate image files almost always win on total bytes transferred.
Yes — that's one of the legitimately strong use cases. A service worker can intercept a request and respond with new Response(base64String, { headers: { 'Content-Type': 'image/png' } }), or your HTML shell can carry status icons as inline data: URIs so they render even when the network is offline and the image cache is cold. Keep the inlined assets tiny — every byte in the precache manifest is byte that has to install before the PWA becomes installable.
Strip the data:image/...;base64, prefix and base64-decode the remainder. For a downloadable file without writing any code, paste the string into Base64 Decoder — it handles both raw strings and full data URIs and gives you the binary back. In Node it's Buffer.from(b64, 'base64'); in Python base64.b64decode(b64); in a browser await (await fetch(dataUri)).blob().
Browsers don't officially document a hard cap on data: URI length, but practical limits exist. Older guidance pegged IE at 32 KB; modern Chrome, Firefox, and Safari handle multi-megabyte data URIs but performance degrades — long URIs slow HTML parsing and DevTools rendering, and copying multi-MB strings around your code editor is its own kind of pain. If your asset is over ~10 KB, the right answer is almost always an external file plus aggressive caching, not a longer base64 string.
No. The page reads the image with FileReader.readAsDataURL() directly in your browser and never uploads anything. The encoded output exists only in the tab you have open — close it and the data is gone. That makes the tool safe for screenshots that contain sensitive UI, internal-only logos, or anything else you wouldn't want crossing a network.