Free online image to data URI converter
Image to Base64 with the cost shown
Drop a picture and the data: URI is ready before you finish reading this — free, no account, up to 2 MB, and with the CSS, HTML and Markdown lines already written out underneath. The preview sits over a transparency grid or a dark backdrop so you can see whether the alpha channel survived the export, and the page measures what inlining actually costs: not just the third that Base64 adds, but the gzipped size of the file against the gzipped size of the stylesheet that now contains it. For SVG it also builds the percent-encoded form, which is reliably the smaller of the two.
- 100% free
- No signup
- Up to 2 MB
- PNG, JPEG, WebP, SVG
- CSS, HTML and Markdown
Drop an image here, paste one from the clipboard, or choose a file.
Any raster or vector format the browser can draw, up to 2 MB. Nothing is uploaded — the picture is drawn straight out of memory.
The string appears here the moment an image lands.
No image yet. A screenshot on the clipboard pastes straight in, so does a file dragged from the desktop.
How to convert an image to a data URI
Drop it, look at it, copy the line you need.
Drop the picture in
Drag a file onto the left panel, paste a screenshot straight from the clipboard with ⌘V or Ctrl+V, or use Choose image. PNG, JPEG, GIF, WebP, AVIF, BMP, ICO and SVG all work, up to 2 MB. The preview comes from a blob URL created inside this tab, so it appears immediately and no upload happens at any point.
Check it against the backdrop it will sit on
The three buttons put the image over a transparency grid, plain white or near-black. A logo exported with a white matte instead of an alpha channel is invisible on the grid and obvious on the dark backdrop, and it is much cheaper to notice that here than after the URI is in a stylesheet. Below the frame the panel reports the pixel dimensions and the megapixel count read from the file itself.
Take the URI, or a whole line of code
The right panel holds the data: URI, and the toggle switches it to the bare Base64 payload if you are assembling the prefix yourself. Underneath are three lines ready to paste — a CSS background-image rule with the quotes already in place, an img tag carrying the file's real width and height, and the Markdown form — each with its own Copy button.
Technical specifications
| Formats accepted | PNG, JPEG, GIF, WebP, AVIF, BMP, ICO and SVG — whatever the browser can decode, since the preview is rendered by the browser itself |
|---|---|
| Maximum file | 2 MB (2,097,152 bytes), which produces 2,796,204 Base64 characters. Anything approaching that should be a request, not a data: URI |
| Measured overhead | A 13,459-byte PNG leaves as a 17,970-character data: URI; gzipped, 13,482 bytes against 13,618 — one per cent apart, measured with CompressionStream in the page |
| SVG alternative | Percent-encoded data: URIs are computed alongside the Base64 one. A 246-byte icon: 354 characters as Base64, 281 percent-encoded |
| Preview | Rendered from a blob URL over a transparency grid, white or #18181b, with the intrinsic pixel dimensions and megapixel count read from the decoded image |
| Snippets produced | CSS background-image with quoted url(), an img tag carrying the real width and height attributes, and Markdown image syntax |
| Media type | Taken from the file the browser reported; an SVG with no reported type falls back to image/svg+xml from the extension |
| Price and processing | Free, no signup, no watermark on anything; the file is read by FileReader in this tab and never uploaded |
Frequently asked questions
Does inlining an image actually make the page slower?
Less than the raw character count suggests, and for a different reason than most people expect. Base64 makes the payload a third longer, but almost all of that is recovered by transport compression: a 13,459-byte PNG becomes a 17,970-character data: URI, and gzipped those are 13,482 and 13,618 bytes — a difference of one per cent. What actually costs you is structural. The image no longer has its own cache entry, so changing one line of CSS re-downloads the picture with it; the browser's preload scanner cannot start fetching an image that is not a URL to fetch; and the stylesheet, which blocks rendering, is now carrying pixels.
Why is my data: URI blocked by the Content-Security-Policy?
Because data: is a scheme of its own and 'self' does not cover it. A policy of img-src 'self' allows images from your origin and nothing else, so an inlined picture is refused with a console message naming img-src even though the bytes never left the page. The fix is to list it explicitly — img-src 'self' data: — and the same applies to font-src for an inlined WOFF2 and to style-src if you are generating a stylesheet as a data: URI. Sites that treat data: URIs as a blanket XSS risk usually mean the SVG case, which is a real one.
Should I use Base64 for an SVG?
No — percent-encode it instead, and the file gets smaller rather than larger. SVG is text, most of it letters and digits that a URL carries unchanged, so escaping only the handful of characters that cannot appear raw beats a blanket 33% increase. A 246-byte icon measured here comes to 354 characters as a Base64 data: URI and 281 as a percent-encoded one, a fifth less, and the percent-encoded version is still readable in the stylesheet where a mistyped viewBox can be spotted. This page computes both whenever the file is an SVG and shows which one won.
Why does my data: URI show nothing in a GitHub README?
Because GitHub routes every image through its camo proxy, which fetches by URL over http or https, and there is nothing for it to fetch. The Markdown itself is fine — CommonMark says nothing about which schemes a link may use — so the same line renders correctly in VS Code's preview, in many static site generators and in a plain browser. If the target is a README, commit the file and reference it by path.
Why does the CSS rule break when I remove the quotes?
Because an unquoted url() in CSS has a restricted grammar: it cannot contain parentheses, whitespace, quotes or a handful of other characters without escaping. Base64 uses + and / and = , which are safe, but the media type in front of it may not be — image/svg+xml is fine while a URI carrying a stray bracket is not — and a percent-encoded SVG contains parentheses constantly. Quoting the URI sidesteps the entire grammar, which is why the snippet on this page is written with quotes and why the specification recommends them.
Can I paste a screenshot straight in?
Yes. Take the screenshot to the clipboard — Shift+Ctrl+Cmd+4 on a Mac, Win+Shift+S on Windows — then press the paste shortcut anywhere on this page and the bitmap is picked up as a file. Browsers hand clipboard images over as PNG with no filename, so it is named clipboard-1.png for the download and the media type is set from what the clipboard reported.
Does the browser cache a data: URI?
Not on its own, and that is the trade in one sentence. A data: URI has no URL, so it has no cache entry, no ETag and no expiry — it is cached only as part of whatever file contains it, and it is re-downloaded whenever that file changes. For an icon inside a stylesheet you already ship on every page this costs nothing. For anything a visitor might see once, a normal image request with a long max-age is strictly better.
About inlining images as data URIs
The data: URI was defined in RFC 2397 in 1998 to solve a small problem — how to write a short piece of content where a URL belongs — and it has been asked to solve a much larger one ever since. The syntax isdata:[media type][;base64],payload, and the media type is the part that matters most: a browser draws the picture according to what the URI says it is, not according to what the bytes are, so a JPEG announced as image/png renders as a broken icon. That is why this page takes the type from the file object rather than from the extension, and why a screenshot pasted from the clipboard keeps the type the clipboard declared.
Whether to inline at all is a question with a measured answer rather than an opinion. The 33% that Base64 adds is real but largely temporary: transport compression is applied after encoding, and gzip finds most of the redundancy the encoding introduced — the figures in the spec table above were produced by the page itself, and put a Base64 PNG about one per cent above the same PNG as a file once both are compressed. The durable costs are the ones nobody measures. An inlined asset has no URL, so it has no cache entry of its own and is re-fetched with every change to the file that carries it. It cannot be discovered by the preload scanner, which reads the HTML for URLs to start fetching before the parser reaches them. And it lands inside a render-blocking stylesheet if that is where you put it. Small, always-needed, rarely-changing assets win on all three counts; photographs lose on all three.
SVG deserves its own rule, because Base64 is simply the wrong tool for it. Vector markup is text made mostly of characters a URL already accepts, so percent-encoding touches only the angle brackets, the hash signs and the quotes, while Base64 charges a third of the file regardless. The percent-encoded form stays readable in the stylesheet, which means a wrong fill colour is a one-character edit rather than a round trip through a decoder. Everything that is not an image — fonts, PDFs, archives, anything the browser will not draw — goes through the general file encoder, and a string that arrived from somewhere else and needs identifying rather than producing belongs in the decoder.
What happens to the picture you drop
It stays on your machine. The browser hands the file's bytes to JavaScript running in this tab, the preview is a blob URL that only this tab can resolve, and the Base64 is built in memory — there is no upload endpoint in this page and no request is made while it works. Screenshots of dashboards and internal designs go through tools like this every day, which is the reason it is built without a server side at all.