Anatomy of a data URI
A data URI has four parts: data:image/png;base64,iVBORw0KG... — the scheme, the MIME type, the encoding marker, and the payload. The MIME type must match the actual image format or some browsers will refuse to render it; this tool detects the type from the file’s binary signature, not its extension, so the generated URI is always consistent with the real content.
The caching trade-off nobody mentions
A file served from /logo.png is downloaded once and cached for every page that uses it. The same logo inlined as Base64 is re-downloaded inside every HTML document and every stylesheet that embeds it, and it can’t be cached independently. The practical rule: inline only what is unique to a page or genuinely tiny; anything reused across pages belongs in a cacheable file. If you inline an image inside a CSS file, that’s a middle ground — the stylesheet itself is cached once.
SVG: consider skipping Base64 entirely
SVG is already text, so Base64-encoding it adds 33% overhead for no benefit. A URL-encoded SVG data URI (data:image/svg+xml;charset=utf-8,%3Csvg...) is smaller and remains human-readable in your CSS. Use Base64 for SVG only when the markup contains characters that make URL-encoding awkward, or when a build tool requires it.
Quick reference: where each output format goes
- Raw string — JSON payloads, configuration files, programmatic use
- CSS —
background-image: url(data:...)for decorative images and icons - HTML —
<img src="data:...">for content images in emails and standalone files - Markdown — works in most renderers via the HTML image syntax, useful for self-contained README files