Base64 in CSS, Email and SVG: Where It Truly Pays Off
We've already established that Base64 loses on size, and almost always on speed too. And yet it hasn't vanished from practice, because in three specific scenarios an embedded image does something a plain file can't. Let's walk through those scenarios with code examples — and be honest about where, even there, you should pump the brakes.
Scenario 1: icons in CSS
The most popular use of Base64 is embedding a small icon straight into your styles via the background property. No separate file, no extra request: the icon arrives with the CSS and renders immediately.
.search-input {
background: url("data:image/svg+xml;base64,PHN2ZyB4bWxu
cz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIC4uLg==") no-repeat 8px center;
padding-left: 32px;
}This works for tiny decorative elements: checkmarks, arrows, the magnifier in a search field, list bullets. If you're unsure how an image turns into such a string, start with "What is Base64," and our converter will produce the string for you.
Critical CSS and the first screen
Here the trick gains a real speed benefit. Critical CSS means the handful of styles you place right inside the page itself, instead of in a separate file, so the top of the page can appear before everything else has finished loading. If those styles contain a background icon embedded as Base64, it appears with no request at all — at the same moment the content first shows.
The win here isn't size, it's the absence of delay: the user sees no flash of empty space while an icon file loads. But the rule stands — small only. A heavy image in critical CSS bloats the <head> and, conversely, slows the first paint.
When it's appropriate
An icon of a couple of kilobytes needed on the first screen is a great candidate for Base64 in critical CSS. Everything else is better loaded as cacheable plain files. More on the balance in "Base64 vs files."
Scenario 2: images in email
Email is perhaps the one place where Base64 has a truly unique advantage. Many email clients block external images by default: until the user clicks "show images," they see an empty frame instead of a logo. It's a privacy measure — an external image can track that the email was opened.
A Base64-embedded image is part of the email itself, not an external resource, so it shows immediately with no permission needed. For a header logo or a small icon this is a lifesaver: the email looks whole from the first second.
<!-- Logo in an HTML email -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..."
alt="Company logo" width="120" height="40">
The email pitfalls
But email is also where an unpleasant catch hides. Support for embedded images across mail clients is uneven: some of them, notably classic Outlook and the Gmail web app, have a poor track record with embedded images in email — sometimes displaying them badly, sometimes not at all.
So in email, Base64 is not a universal fix but a trade-off for a specific job. The practical approach: small decorative icons can be embedded, but key large images are safer linked normally, accepting that some users will first see a placeholder.
Test on clients
Before a mass send, always test the email across different clients. What renders perfectly in one may stay an empty frame in another. Never rely on Base64 in email blindly.
Scenario 3: SVG — a special case
SVG is more interesting. Because SVG is itself text, encoding it as Base64 is often redundant. A vector icon can be placed in HTML directly — as <svg>…</svg> markup, with no wrapper at all. And for CSS there's a lighter alternative — URL-encoding (also called percent-encoding): it swaps only the few unsafe characters for codes like %20 and leaves the rest of the SVG as plain, readable text. For SVG it's usually more compact than Base64 and stays readable on top of that.
| SVG embedding method | Size | Readable |
|---|---|---|
Inline <svg> in HTML | smallest | Yes |
| URL-encoding in CSS | compact | Yes |
| Base64 in CSS | +33% | No |
The takeaway: for SVG, Base64 is mainly justified where the alternatives are awkward — for instance inside a complex CSS background. In most cases inline markup or percent-encoding is better.
The shared rule
Running through all three scenarios is a single thread — size decides everything:
Embed only small things in Base64: icons, bullets, small logos. CSS and emails with big data strings bloat, lose caching and render slower. The full picture of pros and cons for the web is in "Base64 images on the web."
A checklist before you embed
- Is the image genuinely small? Aim for under 5 KB. If it's bigger, a separate file is almost certainly better.
- Is the MIME type correct?
image/png,image/jpegorimage/svg+xml— a mismatch and the browser won't show the image. - Is it an email? Then test across several clients: what works in one may fail in Outlook or the Gmail web app.
- Is it an SVG? Consider inline markup or percent-encoding first — they usually beat Base64.
The ready string for any of these scenarios is easiest to get from a converter — it picks the right data: prefix for the file type automatically.
Get a Base64 string for CSS or email
Encode a small PNG to Base64 online — a ready data URI for your styles or email in a couple of seconds.
Convert PNG to Base64Need to pull an image back out of a string? Base64 → PNG has you covered. Every converter is on the all formats page.
Frequently asked questions
Read next
WebBase64 Images on the Web: Pros and Cons
When embedded images speed a site up, and when they slow it down.
ComparisonBase64 vs Plain Image Files
Size, cache and requests — what is faster in the end, and when.
How-toHow to Convert an Image to Base64 and Back
Online, in the browser, and in code — step by step.