Data URI converter

Inline a file as base64 — and find out whether you should.

Or drop it here, or paste. Images, SVG, fonts: any file. Nothing is uploaded.

Copy as

Snippet

The raw string, for anywhere a URL goes.

Choose a file, drop one anywhere on the page, or try the sample.

What data URI is

A URI that carries a file’s bytes inline, base64-encoded, instead of pointing at one. Encoding is trivial and always succeeds, which is the problem: nothing in the conversion tells you that inlining a 200 KB photograph into a stylesheet is a self-inflicted performance problem.

What this tool does that others do not

  • The real encoded size, and a verdict

    Base64 encodes three bytes as four ASCII characters, so the inflation is fixed at 4:3 regardless of content. The figure shown is the real encoded length rather than an estimate, next to a judgement about whether inlining is the right call at that size.

    The sensible ceiling used here is 4 KB. A 3,072-byte file encodes to exactly 4,096 characters.

  • What inlining costs, spelled out

    Caching first: an external file is fetched once and reused across every page, while an inlined one is re-downloaded with every document or stylesheet that embeds it. You also lose srcset and responsive images, lazy loading, and any CDN image optimisation, because there is no URL left to negotiate over. In a stylesheet there is a third cost — the base64 is render-blocking, and one unrelated CSS edit invalidates the cached copy of every asset embedded alongside it.

  • It does not break on non-ASCII or large files

    The common shortcut for this conversion fails on any byte above 0x7F and blows the call stack on large files. This uses the native Uint8Array base64 encoder where the browser has it, with a chunked fallback everywhere else.

How to use it

  1. Drop the file in and read the encoded size

    That number, not the original size, is what will be added to your document.

  2. Compare the file against the 4 KB rule of thumb

    The verdict is judged on the original file: under 4 KB, which is about 5.5 KB once encoded, one fewer request usually wins. Above it, the caching loss wins, and it keeps winning as the page is visited again.

  3. Take the CSS or HTML snippet, not the raw string

    A wrong MIME type can stop the file rendering; browsers guess some image types from their bytes, but an SVG labelled as anything other than image/svg+xml is not drawn. The snippet gets the type right for you.

Worked examples

Real input, real figures.

Working out what inlining will add

You give it

A 3,072-byte SVG icon.

You get

Exactly 4,096 characters of base64 — a fixed 33% inflation. Compression recovers less of that than people expect, because base64 deliberately destroys the byte patterns a compressor looks for. At this size, inlining is a reasonable trade for one fewer request.

A file that should not be inlined

You give it

A 200 KB photograph destined for a stylesheet.

You get

About 267 KB of base64, render-blocking, re-downloaded with every page that loads the stylesheet, and invalidated by any unrelated CSS edit. The conversion still succeeds — which is exactly why the verdict is shown beside it.

Against a plain base64 encoder

AspectThis toolA plain encoder
OutputEncoded size, overhead and a verdictA wall of text
GuidanceWhat inlining costs, itemisedNone
Non-ASCII contentNative encoder with a chunked fallbackOften throws
Large filesChunked, so no stack overflowCommonly crashes
SnippetsCSS and HTML with the right MIME typeThe raw string

Guide

The encoding is the easy part

Converting a file to base64 takes four lines of code, and every tool that does it hands back a wall of text with no further comment. That is the problem: the conversion always succeeds, so nothing tells you that inlining a 200 KB photograph into a stylesheet is a self-inflicted performance problem.

The 33% inflation is fixed and unavoidable — base64 encodes 3 bytes as 4 characters. What varies is whether that trade is worth one fewer request, and past a few kilobytes it stops being worth it. This tool gives the encoded size and the reasons, then lets you decide.

Questions people ask

Straight answers. Each one links directly: copy the address after opening it.

When should I inline a file as a data URI?

When it is small, used in one place, and self-contained — a single icon in an inline style block is the textbook case. Roughly 2 to 4 KB is the sensible ceiling. The saving is one fewer HTTP request; the cost is a flat 33% size increase plus the loss of caching, and above a few kilobytes the cost wins.

Why does base64 make files 33% bigger?

Because it encodes every 3 bytes of binary as 4 ASCII characters, so the ratio is fixed at 4:3 regardless of content. Compression recovers some of that in transit but less than you would expect, since base64 deliberately destroys the byte patterns a compressor looks for. The figure shown here is the real encoded length, not an estimate.

What do I lose by inlining an image?

Caching, first: an external file is fetched once and reused across every page, while an inlined one is re-downloaded with every document or stylesheet that embeds it. You also lose srcset and responsive images, lazy loading, and any CDN image optimisation, because there is no URL left for the browser to negotiate over. In a stylesheet there is a third cost — the base64 is render-blocking, and one unrelated CSS edit invalidates the cached copy of every asset embedded alongside it.

Does this handle non-English filenames and content?

Yes. The common shortcut for this conversion breaks on any byte above 0x7F and blows the call stack on large files. This uses the native Uint8Array base64 encoder where the browser has it, with a chunked fallback everywhere else.

Is my file uploaded?

No. The file is read into memory in your browser and encoded there. Nothing is sent anywhere, which also means there is no size limit beyond your own available memory.