Base64 DataURI Bench

See the exact encoding overhead before you inline an image or font as a Data URI. Your file never leaves your browser.

100% client-side

File

Drop an image or font file here, or

Overhead analysis

Original size
—
Base64 payload size
—
Overhead
—
Full Data URI size
—
Load a file to see the embed-or-not verdict.

        
      

What is a Base64 Data URI?

A Data URI lets you embed a file — like an image or a font — directly inside your HTML or CSS as a block of text, instead of linking to a separate file the browser has to request. To turn binary data into text-safe characters, it gets run through Base64 encoding first, which is what makes the resulting string noticeably longer than the original file. This tool measures exactly how much longer, and tells you whether embedding is actually a good idea for your specific file.

How to use Base64 DataURI Bench

  1. Drop an image or font file onto the File panel, or click "browse files" to pick one (or click Example to try a sample file).
  2. Read the size breakdown in the Overhead analysis panel: original size, Base64 payload size, overhead, and total Data URI size.
  3. Check the verdict box for a plain-English recommendation on whether inlining this file is worth it.
  4. Click Copy Data URI to copy the ready-to-use string into your HTML or CSS.

How the overhead is calculated

Base64 (RFC 4648) represents binary data using only 64 printable characters, packing every 3 raw bytes into 4 output characters:

encoded_size = ceil(original_size / 3) * 4

// Example: a 300-byte icon
ceil(300 / 3) * 4 = 400 characters → +33.33% overhead

// Example: a 301-byte icon (not a multiple of 3)
ceil(301 / 3) * 4 = 404 characters (includes "=" padding) → +34.22% overhead

The overhead is always close to 33%, but the exact percentage shifts slightly around file sizes that aren't a multiple of 3 bytes, because of the padding character(s) added at the end. This tool computes the real figure for the file you load rather than showing a flat "33%" for every file.

The size math is only half the story — inlining also means the browser can't cache or reuse that asset independently of the page/CSS/JS it's embedded in, and large inline strings slow down HTML/CSS parsing. That's why the rule of thumb below is about total request economics, not just byte count.

Frequently asked questions

Why is a Base64 Data URI always about 33% bigger than the original file?

Base64 packs every 3 raw bytes into 4 printable characters (RFC 4648), so the encoded size is always ceil(originalBytes / 3) * 4 — a fixed ~33% expansion that has nothing to do with what's inside the file.

When is it worth inlining an image or font as a Data URI?

Roughly under ~2KB, where avoiding an extra HTTP request tends to outweigh the Base64 overhead. Above that, a real cached HTTP/2 request is usually more efficient — this is general guidance, not an absolute rule, since caching and multiplexing change the tradeoff per project.

How is this different from the site's Base64 Switch tool?

Base64 Switch is a generic text/JSON/file Base64 encoder-decoder. This tool is specifically for images and fonts, and its focus is the overhead analysis and embed-or-not verdict rather than plain conversion.

Is my file uploaded anywhere?

No. The file is read locally with the browser's File API and encoded with btoa() in your browser — it never leaves your machine.