Image ↔ Base64 Data URL

Turn an image into a data URL – or paste a data URL and immediately see what is inside. Works the same way for SVG, fonts, text and other files. Everything runs locally in your browser.

What a data URL is

A data URL (defined in RFC 2397) packs a file's content straight into the address instead of pointing at a file on a server. So the browser fetches nothing – the data is already there. The structure is always the same:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUg…
└───┘└───────┘└─────┘└──────────────────────┘
  │      │       │               │
  │      │       │               └── the data itself
  │      │       └── Encoding (if absent, percent encoding applies)
  │      └── MIME type (if absent, text/plain applies)
  └── Scheme

What data URLs are used for

The best-known case is images – as <img src="data:…"> or in CSS as a background-image. Just as common, though, are:

• SVG icons in CSS. Here percent encoding beats Base64: because SVG is readable text, most of it stays untouched and the URL comes out shorter than with Base64 – roughly 5 to 10% for typical icons.
• Fonts in @font-face. Saves a network round trip and avoids the brief flash when the font swaps in – at the cost of cacheability, see below.
• Download links without a server. A data:text/csv;… link produces a downloadable file purely in the browser, with no backend at all.
• Email templates and embedded thumbnails, where external resources should not or cannot be loaded.

Base64 or percent encoding?

Base64 turns arbitrary bytes into 64 printable characters and is the right choice for binary files such as PNG, JPEG or WOFF2. The price is an overhead of about a third: three bytes become four characters.

Percent encoding leaves everything that is allowed in a URL anyway as it is and writes only the problematic characters as %XX. For text formats – SVG above all – it is therefore usually more compact and readable in source. For binary files it is much worse, because there nearly every byte has to be encoded. The tool above shows you which of the two comes out shorter for your specific file.

When not to use data URLs

Data URLs are a tool for small files – icons, logos, placeholders. For larger files the trade-off flips, for several reasons:

An embedded file is not cached separately. It is part of your HTML or CSS and gets transferred in full on every page load, whereas a normal image file sits in the browser cache after the first load. On top of that comes Base64's one-third overhead, and in CSS the inflated file additionally blocks the page's first render. As a rough rule of thumb: below about 5 KB almost always worthwhile, above that look closely, and from a few tens of kilobytes on almost always the worse choice.

FAQ

Are my files uploaded anywhere?
No. The file is read through your browser's File API and encoded right there. There is no server that could see it – you can even go offline after the page has loaded.

Why is my PDF not displayed?
For security reasons modern browsers block top-level navigation to data: URLs, and PDFs can no longer be embedded that way. The data URL itself is still correct – you can get the file out via the download button.

Why is HTML only shown as source?
Because executing pasted HTML would mean running foreign script in the context of this page. This tool therefore deliberately shows HTML from a data URL as text only.

Can I paste a data URL without the “data:” header?
Yes. If you only have the bare Base64 part, the tool recognises the file type from the first bytes – PNG, JPEG, GIF, WebP, PDF, WOFF and several more carry a unique signature there.

Is there a size limit?
Technically it is mainly memory that limits you today. Older browsers had hard limits (Internet Explorer around 32 KB) that no longer matter. In practice you should go by the rule of thumb above rather than by the technical maximum.