Data URI Converter

About Data URI Converter

A data URI is a URL that carries the file itself. It looks like data:image/png;base64,iVBOR…, and if you put that string in an img src or a CSS url(), the browser shows the image without downloading a separate file. The format was defined in RFC 2397 in 1998.

This tool works both ways. Drop in a file and it produces a Base64 data URI, the size change, and a ready-to-paste CSS snippet (background-image, or an @font-face rule for fonts). Paste a data URI and it shows the MIME type, the encoding and the decoded size, previews images, and lets you save the content as a file.

Reading a data URI

The grammar is data:[media type][;base64],data. Everything before the first comma describes the payload; everything after it is the payload. If the media type is omitted, RFC 2397 says to assume text/plain;charset=US-ASCII. So data:,Hello%2C%20World%21 is a perfectly valid data URI; this tool reads it as text/plain, 13 bytes, “Hello, World!”.

With ;base64, the part after the comma is Base64. Without it, the data is percent-encoded. This tool turns each %XX straight into that byte instead of reading it as UTF-8, so binary such as %FF%00 or charset=EUC-KR text comes back intact, and the charset travels with the downloaded file's type. Binary files — images, fonts — are almost always Base64. SVG and short text are often smaller percent-encoded: SVG is already text, so Base64 inflates it by a third, whereas percent-encoding only touches a handful of characters such as <, > and #.

Size: the 33% figure only holds for large files

Base64 writes 3 bytes as 4 characters, so the payload is ceil(n/3) × 4 characters, and data:image/png;base64, adds 22 more in front. A 30,000-byte PNG becomes 40,000 Base64 characters and a 40,022-character URI: +33%. A 100-byte icon becomes 136 Base64 characters (+36%) but 158 characters in total (+58%). That's why the tool reports the two increases separately.

When inlining hurts

The benefit of a data URI is one fewer HTTP request. Under HTTP/1.1, with a handful of parallel connections per host, inlining dozens of small icons was a clear win. HTTP/2 multiplexes many requests over one connection, which shrinks that benefit a lot. The costs haven't changed:

• No independent caching. An inlined image is cached only as part of the CSS or HTML that contains it. Change the logo and every visitor re-downloads the whole stylesheet; inline it in page HTML and every page carries its own copy of the same bytes.
• Render blocking. Browsers don't paint until the CSS has arrived, so a large data URI inside CSS delays first paint by however long those extra bytes take. As a separate image file, text could have shown first.
• No prioritization or lazy loading. loading="lazy" and responsive srcset stop meaning anything; an off-screen image arrives with everything else.
• It's bigger. gzip or Brotli on the containing file claws some of the 33% back, but the result is still larger than serving the original image bytes.

Where it still makes sense

Tiny icons and patterns of a few hundred bytes, a loading spinner used once, HTML email where external images are often blocked, single-file reports, and documents that must open offline. Inlining a web font in @font-face avoids the flash of fallback text while the font downloads, but font files are usually tens of kilobytes, and all of that lands in your CSS on every uncached visit.

A security note: to curb phishing, major browsers block top-level navigation to data: URLs — typing one into the address bar or following a link to data:text/html won't open a page. Using data URIs inside images and stylesheets is unaffected.

Worked examples

How to use it

1. File → data URI: drop or choose a file to get the URI, the size change and a CSS snippet.
2. For a font, enter a family name and copy the generated @font-face rule.
3. Data URI → file: paste the string to see its type and size, preview images, and save the content.

Frequently asked questions