CSS Data URI Converter

Inline the images your stylesheet references as Base64 data URIs — free, browser-based, nothing uploaded

1. Paste your CSS

2. Add the image files

Drop all your images at once

We match them to url() references by filename

3. Copy the inlined CSS

Twelve Icons, Twelve Requests, One Slow Page

Your stylesheet references a dozen small images. Each one is a separate round trip, and on a phone that adds up. Encoding them by hand means twelve conversions and twelve careful find-and-replaces. This CSS data URI converter does the whole file at once.

Paste the CSS, drop the images in, copy the result. We match files to references by name, so folder structure does not matter.

And when a file is too big to inline safely, we say so rather than letting you slow your own site down.

How to Inline CSS Images as Base64

Paste your stylesheet. Every url() reference is listed straight away.
Drop in all the images at once. Multi-select works.
Check the status list. Green means done, amber names the missing file.
Read the size warning. Anything over 10 KB gets flagged.
Copy the output. Before and after sizes are shown.

You do not have to inline everything. Add only the files worth inlining and the rest stay as normal references — that is usually the right answer anyway.

Why We Cannot Just Read Your Image Files

The obvious question: your CSS says url("images/logo.png"), so why not fetch it?

Because a web page cannot reach into your project folder. That path means nothing outside your own server, and browsers deliberately block any page from reading local files it was not handed.

Dropping the files in is the workaround. It is one extra step, and it is also the reason nothing you put here is ever uploaded.

Same rule applies to images on other domains. We mark those skipped and leave the reference alone, because reading them would need CORS permission you almost certainly do not have.

The 10 KB Line, and Why a Data URI in CSS Costs More Than in HTML

A stylesheet is render-blocking. The browser will not paint a single pixel until the whole file has downloaded and parsed.

So every byte you inline is a byte every visitor waits for before seeing anything. A 500-byte icon is invisible in that budget. A 200 KB illustration is not.

The same image inside an HTML img tag is far less damaging, because the browser paints around it. That difference surprises people, and it is why we flag CSS specifically.

Our working rule: under 2 KB inline freely, 2 to 10 KB think about it, above 10 KB host the file. The tool warns at 10 KB rather than blocking, because occasionally you have a good reason.

We go through the numbers behind that line in when Base64 images are worth it.

The Caching Trade You Are Making

This is the part most guides skip. A normal image file gets cached on its own — downloaded once, reused on every page and every later visit.

Inlined, it becomes part of the stylesheet. Change one unrelated CSS rule and every embedded image downloads again with it.

In our experience that is where inlining quietly loses. The saved request looks good on a first-load waterfall and costs you on every visit after.

The assets worth inlining are therefore small, critical, and stable. Anything you edit often belongs in its own file.

Fonts Are the Wrong Thing to Inline

The tool accepts WOFF and WOFF2 files because people ask for it. We would still talk you out of it.

Fonts run 20 to 100 KB each, well past the point where render-blocking hurts. They are also the asset browsers cache hardest, since the same font serves every page on your site.

Inline one and you pay for it on every visit, forever, to save a single request on the first.

Use font-display: swap and a preload hint instead. That solves the flash of invisible text without any of the cost.

What to Do Before You Convert

Two steps that matter more than the conversion itself:

Compress the images. Base64 adds a third to whatever you feed it, so shrink first with our image compressor.
Run SVGs through an optimiser. Design-tool exports carry editor metadata and twelve decimal places of precision.

For a one-off asset rather than a whole stylesheet, the image to Base64 converter outputs a ready-made CSS rule. And for SVG specifically, the SVG to Base64 encoder also produces a percent-encoded version, which is usually shorter.

New to the format? Our explainer on what a data URI is covers the syntax and the browser limits.

Frequently Asked Questions

Why do I have to upload the images instead of the tool fetching them?

Because your CSS uses relative paths, and a browser page has no access to your project folder. Nothing running on this page can read images/logo.png off your disk. Dropping the files in is the workaround, and it also means nothing is uploaded anywhere.

What happens to url() references pointing at another domain?

We leave them alone and mark them skipped. A cross-origin image cannot be read without CORS headers, and inlining a third-party asset usually breaks their caching anyway. The rest of your stylesheet still converts.

Two folders contain a file with the same name. Which one wins?

The last one you dropped in, because we match on filename alone. This is the one real limitation of the approach. Rename the duplicates before converting, or run the two stylesheets separately.

Will inlining break my CSS source maps?

Not the map itself, but the line offsets become useless. Each data URI is thousands of characters on one line, so anything mapping to positions after it points to the wrong place. Convert as a build step, after the map is generated.

Should I inline web fonts as well as images?

Almost never, and it is the mistake we see most on this page. A font file is typically 20 to 100 KB, and fonts are the asset browsers cache most aggressively across pages. Inlining one costs you that cache on every single visit.

Does this help or hurt Largest Contentful Paint?

Both, depending on size. Removing a request helps a small icon appear sooner, but the payload sits inside a render-blocking stylesheet. Past roughly 10 KB the blocking cost wins and your LCP gets worse.

My CSP blocks the converted stylesheet. What changed?

Your policy does not allow the data: scheme. A default img-src self directive blocks every data URI you just created. Add data: to img-src explicitly — but not to script-src, where it is a genuine security hole.

Why did my SVG break after conversion?

Almost certainly a hash character. We Base64 the file rather than percent-encoding it, which sidesteps that, but a hand-edited data URI with a raw # will truncate at the first hex colour. Escape it as %23.

Does gzip cancel out the size increase?

Partly for SVG, barely for PNG and JPEG. Those are already compressed, so there is little left for gzip to find. Expect the converted stylesheet to be a few percent larger over the wire, not the same size.

Can I run this on a whole stylesheet from a framework?

You can, but think about whether you should. Bootstrap or Tailwind output references very few images, and the ones it does are usually tiny already. The gain is small and the file becomes much harder to read.

The Short Version

Paste, drop, copy. A CSS data URI converter saves you a dozen manual conversions, and this one tells you when inlining is a bad idea.

Inline the small and stable. Host everything else, and let the browser cache do the work it is good at.

Related Tools You Might Like

JSON Formatter

Format, validate, and minify JSON data

HTML Minifier

Minify HTML code for better performance

Color Picker

Pick colors and generate beautiful color palettes

Website Content Extractor

Extract structured content, meta tags, and SEO data from any website

Google Dork Generator

Build advanced search operator queries without memorising the syntax

Google Search Operators

Every search operator, tagged with whether Google still supports it