Data URI Images

## Why it matters

Small icons and placeholders are often inlined as data URIs to save HTTP requests. A site might embed a 2 KB logo as a data URL inside the CSS to avoid an extra round-trip. The URL has no file behind it, only the encoded bytes inside the string.

To save such an image you have to decode the string back into binary. And because the size is encoded right there, you can know how large an image is without downloading it again. A scanner that skips data URIs loses every inlined image; one that decodes them finds images that ordinary tools can't touch.

## How it works

A data URI follows the format data:[<mediatype>][;base64],<payload>. The mediatype is optional and defaults to text/plain. If the data is base64-encoded (almost always the case for images), you include ;base64 before the comma. Everything after the comma is the encoded payload.

To decode a base64 image, you turn the string back into binary, then make the browser treat it as an image. The simplest way is to drop the full data URI into an <img src> and let the browser render it.

For file size, base64 encoding expands the original by roughly 33 per cent. If the base64 payload is 1000 characters long, the decoded binary is about 750 bytes. You can compute this precisely: base64 groups input into 4-character chunks, so divide the payload length by 4, multiply by 3, and subtract any padding (=) characters.

## What does not matter

Whether the data is base64 or percent-encoded does not affect saving it. Both can be decoded to the original binary. Base64 is far more common for images.

Also, the MIME type in the data URI is advisory. A string claiming data:image/jpeg;base64,... might actually be PNG data. If you're saving programmatically, don't rely on the claimed type; let the browser or a file-format detector tell you what you actually have.

Very large data URIs bloat the HTML and delay the first paint. A 500 KB photo embedded as base64 makes the page 665 KB heavier and blocks parsing until it's loaded. This is why inlining only makes sense for tiny images, typically under 5 KB. Scalpel Images skips data URIs above a size cap to keep the popup responsive.

## Code example

Here's a tiny inline image:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==" alt="red dot" />
Copy

To extract and save this data URL, you'd decode it like this:

const dataUrl = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==";

// Extract the base64 part
const base64String = dataUrl.split(',')[1];

// Compute decoded size (base64 is 33% larger)
const byteLength = Math.ceil(base64String.length * 0.75);
console.log(`File size: ${byteLength} bytes`);

// Decode to binary and save as a Blob
const binaryString = atob(base64String);
const bytes = new Uint8Array(binaryString.length);
for (let i = 0; i < binaryString.length; i++) {
  bytes[i] = binaryString.charCodeAt(i);
}
const blob = new Blob([bytes], { type: 'image/png' });
Copy

## How Scalpel Images shows it

Every data URI is tagged with a DATA badge and a colour chip labelled "data" in the image list. The exact KB weight is computed from the base64 payload and displayed on the tile. You can filter by the "data" chip to see only inlined images, and download them through the standard naming pipeline.