Image to Base64 — Data URI Generator
Drop in an image and get a data URI you can paste into a stylesheet, an HTML attribute or a Markdown file. The encoding happens in your browser, so the image is never uploaded — which matters, because a data URI is the whole file in plain text.
Drop an image here or browse
PNG, JPG, SVG, GIF, WebP, ICO · one at a time · nothing is uploaded
Preview
The full string, ready to drop into a src attribute.
Decode a data URI back into an image
What a data URI actually is
A data URI is a whole file written as a URL. The shape is fixed: the scheme data:, then the media type, then optionally ;base64, then a comma, then the payload. So data:image/png;base64,iVBORw0KGgo… says "what follows is a PNG, Base64 encoded". Nothing fetches anything; the bytes are already there.
Base64 exists because a URL cannot contain arbitrary bytes. It maps every three bytes onto four characters drawn from a 64-character alphabet that survives being pasted into text. Four characters for three bytes is where the 33% overhead comes from, and it is not avoidable — it is arithmetic, not an implementation detail. Padding with = at the end rounds the input up to a multiple of three.
It is worth saying plainly: Base64 is not compression and it is not encryption. It makes the file bigger and anyone can read it back. The stats above show the real cost.
When inlining is worth it
The argument for a data URI is that it removes a network request. That argument was much stronger before HTTP/2, when browsers opened a handful of connections per host and every extra file queued behind the others. Today multiplexing makes small requests cheap, and the case for inlining has narrowed to a few situations:
- Tiny assets — icons, patterns, a 1 px gradient — under roughly one or two kilobytes.
- Something that must exist even if the rest of the site is unreachable, such as an offline page.
- A single file you need to hand someone with no hosting attached: an HTML email template you will paste elsewhere, a bookmarklet, a self-contained report.
The argument against it is caching. An image referenced by URL is cached once and reused everywhere. The same image inlined into a stylesheet is downloaded again every time that stylesheet changes, cannot be lazy-loaded, cannot be served in a different format to browsers that support one, and sits in the critical path blocking the first render. Inline a 200 KB photo into your CSS and you have made every page on the site 270 KB slower to start painting.
SVG should not be Base64 at all
SVG is already text. Base64 encoding it adds a third to the size for no benefit and makes it unreadable. Percent-encoding the handful of characters that would break a CSS url() keeps it short, keeps it legible, and compresses far better over the wire, because gzip can find repetition in XML and cannot find any in Base64. This tool does that automatically when you give it an SVG.
Things that will bite you
- Email clients. Gmail and several others refuse to render an image from a data URI. If the target is an email, host the image and link to it.
- Content Security Policy. A policy of
img-src 'self'blocks data URIs. The directive needsdata:added explicitly, and some teams will not allow that. - You cannot open one in the address bar. Browsers have blocked top-level navigation to
data:URLs for years, because it was an easy phishing trick. Use the decoder panel above instead. - Markdown support is patchy. It works in many renderers and is stripped in GitHub comments.
- Large strings are slow to edit. A megabyte of Base64 in a text box will make your editor, and this page, feel sluggish. That is a hint about what it will do to your build.
The decoder is deliberately forgiving: if you paste a payload with no data: prefix it inspects the first characters and guesses the format from them, because the leading bytes of PNG, JPEG, GIF and WebP are distinctive enough to survive Base64 encoding. A payload that has been line-wrapped by an email client still works; one that has been truncated will decode and then fail to render.
Frequently asked questions
Why is the Base64 version bigger than the original file?
Because Base64 spends four characters on every three bytes, which is a fixed 33% increase, plus a few characters for the prefix. It is an encoding, not a compression format. If you need the file smaller, compress the image before encoding it.
Should I inline images as data URIs?
Only small ones. Under a kilobyte or two the saved request is worth it. Above that the loss of separate caching, lazy loading and format negotiation costs more than the request ever did, especially over HTTP/2.
Can I use a data URI in an email?
Usually not. Gmail and several other clients block data URIs in image tags, so the recipient sees a broken image. Host the file somewhere and use a normal URL, however inconvenient that is.
What is the maximum length of a data URI?
There is no limit in current browsers for an image in a src or CSS url(). The practical limit is your patience: very long strings slow down parsing, editing and every build step that touches the file.
Is my image uploaded when I encode it?
No. The file is read with the browser FileReader API and encoded locally. It never leaves your device, which matters more here than usual, because a data URI is a complete copy of the file in plain text.
Last updated September 19, 2026