A data URI (RFC 2397) embeds a resource's bytes directly inside a document instead of pointing at a separate file. The syntax is `data: [;base64], ` — for example `data:image/png;base64,iVBORw0KGgo…` as the `src` of an ` `.

Why does base64 make files bigger?

Base64 encodes three bytes as four ASCII characters, so encoded data is about 33% larger than the original, before any line breaks. A 6 MB directory of images becomes roughly 8 MB of inline text.

Is there a size limit for data URIs?

Modern browsers accept very large ones, but practical ceilings arrive earlier: the document must fully parse before rendering, nothing is cached or lazily loaded, and mail servers and chat clients reject the resulting file long before the browser would.

When should you use a data URI?

For small assets that must survive being detached from their directory — an icon, a logo, a single chart image inside an emailed export. For a report directory with megabytes of assets, uploading the directory is smaller and faster than inlining it.

Data URI

A data URI (RFC 2397) embeds a resource's bytes directly inside a document instead of pointing at a separate file. It is the mechanism behind every single-file HTML export.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg…" />
<link rel="stylesheet" href="data:text/css,body%7Bmargin%3A0%7D" />

Syntax: data:<mediatype>[;base64],<data>. Without ;base64 the payload is percent-encoded text, which is smaller for CSS and SVG than base64 is.

The 33% tax

Base64 encodes three bytes as four ASCII characters. Encoded data is about a third larger than the original, before any line wrapping.

That is only the visible cost. Inlining also defeats the optimisations that made the multi-file version fast:

No caching. A linked asset is fetched once across every page and every visit. An inlined one is re-parsed on every open.
No lazy loading. An image below the fold parses with the document.
Blocking parse. The browser reaches first paint only after the whole inlined blob has been read.

A 400 KB report with 6 MB of assets becomes an 8 MB single file that takes seconds to open — and still will not attach to most mail servers (too big to email).

Where it is the right call

A logo or icon of a few kilobytes that must survive detachment.
SVG inlined as percent-encoded text, which is often smaller than the extra HTTP request it replaces.
A single chart image in a report someone will genuinely open from an email attachment.

Where it stops working

Whole report directories. Tools whose reports fetch a JSON data tree at runtime — Allure, Playwright, most coverage trees — cannot be inlined at all without rewriting the report (self-contained HTML).

And inlining does nothing about delivery. The file still has to get past attachment limits and chat clients that refuse to preview HTML, and it still arrives as a file on someone's disk with no comments, no versions and no way to know it was read.

The alternative

Upload the directory as it is. Relative references are rewritten to the uploaded copies, so nothing inflates by a third, the reader gets a URL instead of an attachment, and the page loads incrementally the way its author intended.

Limits: entry HTML 5 MB; assets 25 MB per file, 250 MB and 500 files per report. An export that exceeds the 5 MB entry limit is almost always inlined assets — uploading the original directory is the smaller path.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a report directory →