A tool by axiomape.com

Base64 Image Data-URI Injector

Drop an image file and instantly generate an inline CSS background-image rule using a Base64 Data-URI. Zero uploads, 100% private.

Asset Upload Zone and CSS Generator Settings
ASSET UPLOAD ZONE
🖼️
Drag and drop your image here
or click to browse
Accepts .png, .jpg, .svg, .webp, .gif
Recommended: Files under 50KB to prevent CSS blocking.
CSS GENERATOR SETTINGS
The selector for the generated CSS rule.
How the image scales within the element.
Whether the image tiles across the element.
Starting position of the background image.
📂 Drop an image above to generate your CSS output and preview.
Key Terms Explained
Base64 Encoding
A method of converting binary data into a string of 64 printable ASCII characters. It allows arbitrary binary files like images to be safely embedded inside text formats like HTML and CSS.
Data-URI
A URL scheme that allows content to be embedded directly inline using the format data:[type];base64,[data]. Data-URIs eliminate the need for a separate file download.
MIME Type
A label that identifies the format of a file, such as image/png or image/svg+xml. Browsers use MIME types to handle data correctly. The MIME type is the prefix of every Data-URI string.
HTTP Request Overhead
The extra time and bandwidth cost of making a separate network request for each resource. Every linked image requires its own TCP handshake and round trip. Inlining an image removes this overhead entirely.
Render-Blocking CSS
CSS files linked in the HTML head prevent the browser from painting anything to screen until they are fully downloaded and parsed. A stylesheet with large Base64 images is heavier and blocks rendering longer.
Inline Asset
Any resource (image, font, SVG) embedded directly into a CSS or HTML file rather than referenced by an external URL. Inline assets load with the parent file but cannot be cached independently.
FileReader API
A browser-native JavaScript interface that reads local files selected by the user entirely in the browser tab, with zero server involvement. This tool uses readAsDataURL() to convert dropped images.
background-image (CSS)
A CSS property that sets one or more images as the background of an element. It accepts standard URLs or Data-URIs as values, making it the natural target for Base64-encoded inline assets.

The Complete Guide to Base64 Data-URIs in CSS

Inlining images directly into your stylesheet is a powerful but often misunderstood technique. This guide explains exactly what Base64 encoding does, when it helps, when it hurts, and how to use this tool to get the output you need instantly.

How to Use This Tool

1
Drop your image into the upload zone on the left. Any PNG, JPG, SVG, WebP, or GIF file works. The file is processed entirely in your browser - nothing leaves your machine.
2
Adjust the CSS settings on the right. Change the class name to match your existing stylesheet, and pick the background-size, background-repeat, and background-position values you need. The output updates in real time.
3
Check the size metrics above the preview. If the Base64 String Size exceeds 100KB, the card turns red - a warning that inlining this image will meaningfully bloat your CSS file.
4
Copy your output. Use "Copy CSS" to grab the complete ready-to-paste CSS rule, or "Copy Data-URI" if you only need the raw string to use in JavaScript, HTML, or another context.

How Base64 Encoding Works Under the Hood

Every image file on your hard drive is stored as raw binary data - a sequence of bytes, each with a value from 0 to 255. Many of these byte values correspond to characters that have special meaning in text formats (quotes, angle brackets, null bytes), making it impossible to paste binary data directly into a CSS file without corrupting the parser.

Base64 solves this by mapping every possible group of 3 bytes to exactly 4 characters drawn from a safe alphabet of 64 printable symbols: uppercase A-Z, lowercase a-z, digits 0-9, plus (+), and forward slash (/). The result is a string that looks like iVBORw0KGgo... - completely safe to place anywhere a text string is accepted. The browser reverses the mapping when it encounters the Data-URI, reconstructing the original binary image in memory.

The 33% size increase is not a bug or an inefficiency of a particular algorithm - it is a mathematical certainty. 3 input bytes become 4 output characters always. If your source PNG is 30KB, the Base64 string will be approximately 40KB, and your CSS file grows by that exact amount.

When Inlining Makes Sense

The tradeoff is straightforward: inlining removes one HTTP request in exchange for making the parent file larger. This is a good deal only when the request overhead is larger than the size penalty. In practice, this favors small, critical-path assets: a tiny favicon embedded in your main CSS loads with zero extra round trips on every page. A small SVG icon set bundled into a component stylesheet is another legitimate case, particularly in single-page applications where the CSS is already being code-split per route and cached aggressively.

HTTP/2 and HTTP/3 have reduced the per-request overhead that once made inlining attractive. On a modern HTTP/2 server, multiplexed connections mean dozens of small files can be fetched simultaneously with almost no per-file cost. This shifts the math against inlining for all but the smallest assets. If your deployment uses HTTP/2 (which virtually all modern hosting providers do), be conservative: keep Base64-inlined images under 5KB in their original form.

The Render-Blocking Warning

CSS linked in the HTML head is render-blocking. The browser cannot display any content on screen until every byte of every linked stylesheet has been downloaded, parsed, and applied. When you embed a large Base64 image inside a render-blocking stylesheet, you force every visitor to download that image data before seeing anything on the page - even if the image is below the fold and not yet visible. This directly increases your Largest Contentful Paint (LCP) score, which is a Core Web Vital Google uses for search rankings. The 50KB recommendation in the upload zone is a conservative practical limit that avoids meaningful LCP regression on typical connections.

Frequently Asked Questions

Why does Base64 encoding increase my file size by 33%?
Base64 encoding converts every 3 bytes of binary data into exactly 4 ASCII characters. Since 3 bytes becomes 4 characters, the encoded output is always 4/3 the size of the input - a precise 33.3% increase before any additional padding. Binary files like PNG and JPG contain raw byte values from 0 to 255, many of which are not safe to embed directly in text formats like CSS or HTML. Base64 restricts itself to only 64 printable characters (A-Z, a-z, 0-9, +, /), making the string universally safe to embed anywhere text is accepted. The inflation is the cost of that compatibility guarantee.
When should I inline images vs. linking them normally?
Inline Base64 images make sense for very small assets under 5KB - icons, tiny logos, simple UI sprites, or loading spinners - where the overhead of an extra HTTP request outweighs the 33% size penalty. For anything larger, a linked image (standard src or url() reference) is almost always faster: the browser can cache it independently, download it in parallel, and reuse it across pages without re-downloading. A good rule of thumb: if the Base64 string pushes your CSS file past 10KB from a single asset, link it instead. SVG icons embedded in CSS are a common legitimate use case, as their source is already text and the Base64 overhead is minimal.
Does injecting large Base64 strings hurt SEO or page speed?
Yes, significantly, if the strings are large. CSS files are render-blocking by default, meaning the browser cannot paint anything on screen until it has finished downloading and parsing every linked stylesheet. When you embed large Base64 images inside a CSS file, you are forcing the user to download all that image data before a single pixel renders. This directly increases Time to First Contentful Paint (FCP) and Largest Contentful Paint (LCP) - two Core Web Vitals that Google uses as ranking signals. For small assets like a 1KB SVG favicon or a 2KB spinner, the impact is negligible. For a 50KB hero image, inlining will measurably hurt your Lighthouse score.
How do Data URIs affect browser caching?
Data URIs do not have their own cache entry. They live inside their parent resource - typically a CSS or HTML file - and are cached only as part of that file. This has two important consequences. First, the browser cannot reuse a Base64 image across multiple pages independently; each page's CSS that contains the string must be re-downloaded together. Second, if you update just the image, the entire CSS file's cache is busted, even though the rest of the styles are unchanged. By contrast, a linked image URL is cached independently and can be reused across hundreds of pages with a single network request. This cache isolation is one of the strongest arguments against inlining large assets.

SVGs: The Best Candidate for Inlining

SVG files deserve special mention. Because SVG is already a text format (XML), you can embed it in CSS either as a Base64 string or as a URL-encoded raw SVG string (using url("data:image/svg+xml,%3Csvg...")). The URL-encoded approach avoids the 33% size increase entirely and produces a string that is still human-readable and editable. For SVG icons and simple illustrations, URL-encoding instead of Base64-encoding can be meaningfully more efficient. The tradeoff is that URL encoding is slightly more complex to generate and some older CSS preprocessors have length limits on unencoded strings. This tool uses Base64 for universal compatibility across all image types.

All image processing happens entirely in your browser using the native FileReader API. No file data is ever uploaded, stored, or transmitted to any server.