Is embedding background image data into CSS as Base64 good or bad practice?

Question

I was looking at the source of a greasemonkey userscript and noticed the following in their css:

.even { background: #fff url(data:image/gif;base64,R0lGODlhBgASALMAAOfn5+rq6uvr6+zs7O7u7vHx8fPz8/b29vj4+P39/f///wAAAAAAAAAAAAAAAAAAACwAAAAABgASAAAIMAAVCBxIsKDBgwgTDkzAsKGAhxARSJx4oKJFAxgzFtjIkYDHjwNCigxAsiSAkygDAgA7) repeat-x bottom}

I can appreciate that a greasemonkey script would want to bundle anything it can within the source as opposed to host it on a server, that's obvious enough. But since I had not seen this technique previously, I considered its use and it seems appealing for a number of reasons:

1. It will reduce the amount of HTTP requests on page load, thus enhancing performance
2. If no CDN, then it will reduce the amount of traffic generated through cookies being sent alongside of images
3. CSS files can be cached
4. CSS files can be GZIPPED

Considering that IE6 (for instance) has problems with cache for background images, this seems like it's not the worst idea...

So, is this a good or bad practice, why WOULDN'T you use it and what tools would you use to base64 encode the images?

update - results of testing

• testing with image: http://fragged.org/dev/map-shot.jpg - 133.6Kb

• test URL: http://fragged.org/dev/base64.html

• dedicated CSS file: http://fragged.org/dev/base64.css - 178.1Kb

• GZIP encoding server side

• resulting size sent to client (YSLOW components test): 59.3Kb

• Saving of data sent to client browser of: 74.3Kb

Nice, but it will be slightly less useful for smaller images, I guess.

UPDATE: Bryan McQuade, a software engineer at Google, working on PageSpeed, expressed at ChromeDevSummit 2013 that data:uris in CSS is considered a render-blocking anti-pattern for delivering critical/minimal CSS during his talk #perfmatters: Instant mobile web apps. See http://developer.chrome.com/devsummit/sessions and keep that in mind - actual slide

Bradwell

Do some test runs? Would be interesting how much the compression can compensate the fact you base64 encode it. – Incentive

posted the results of the test, also avail on my blog fragged.org/… – Bradwell

Good Question. Just wanted to add that it doesnt work for IE7 and below. But there is some work arounds. Here is a nice article about it jonraasch.com/blog/css-data-uris-in-all-browsers – Verst

Doesn't work on my IE8 either... – Feudist

Adding more PRO: cache limits on cellular devices... CON: some images should be treated as content rather than simple presentation and thus are better fit for HTML IMG tags than CSS background images. – Papa

@DimitarChristoff: I've been a fan of embedding small icons with base64 because of its relative ease (when comparing with aggressive spriting) and was happy to accept the size overhead. Thanks for pointing out that it's not always the case (i.e. gzipped base64 embed may be better in terms of absolute asset size as well) – Voracious

Gzipped base-64 will almost always be worse than just gzipping the original in the first place. It's completely false to suggest that you can only send compressed resources that are text in nature. Most people don't bother with gzipping anything non-text, as there often isn't a huge benefit for images that already have built-in compression, such as PNG. – Reddy

Wrong ! base64 encode 8bit bytes / 6bit bytes. So to growing is significantly more than 10%! Resulting size r = 133% Original size o: r=8/6*o -> r=4/3*o -> r=133.333/100*o – Logue

One disadvantage is that chrome on android renders svgs as bitmaps when used in as a css background-image. More details on the chromium issue tracker: code.google.com/p/chromium/issues/detail?id=161982 – Catalysis

Answer 1

It's not a good idea when you want your images and style information to be cached separately. Also if you encode a large image or a significant number of images in to your css file it will take the browser longer to download the file leaving your site without any of the style information until the download completes. For small images that you don't intend on changing often if ever it is a fine solution.

as far as generating the base64 encoding:

• http://b64.io/
• http://www.motobit.com/util/base64-decoder-encoder.asp (upload)
• http://www.greywyvern.com/code/php/binary2base64 (from link with little tutorials underneath)

Anachronistic

less had a data-uri function that will inline a image lesscss.org/#reference – Knobkerrie

it is a good idea if you want to have minimum protection for those images so they wouldn't* be cached or could be downloaded by right-clicking -> save – Tobit

"It's not a good idea when you want your images and style information to be cached separately" - there's nothing to stop you having all the images in a seperate .css file. – Josiahjosias

My practice and tests does not confirm your statement. Sorry. – Chela

Answer 2

This answer is out of date and shouldn't be used.

1) Average latency is much faster on mobile in 2017. https://opensignal.com/reports/2016/02/usa/state-of-the-mobile-network

2) HTTP2 multiplexes https://http2.github.io/faq/#why-is-http2-multiplexed

"Data URIs" should definitely be considered for mobile sites. HTTP access over cellular networks comes with higher latency per request/response. So there are some use cases where jamming your images as data into CSS or HTML templates could be beneficial on mobile web apps. You should measure usage on a case-by-case basis -- I'm not advocating that data URIs should be used everywhere in a mobile web app.

Note that mobile browsers have limitations on total size of files that can be cached. Limits for iOS 3.2 were pretty low (25K per file), but are getting larger (100K) for newer versions of Mobile Safari. So be sure to keep an eye on your total file size when including data URIs.

http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/

Waly

Answer 3

If you reference that image just once, I don’t see a problem to embed it into your CSS file. But once you use more than one image or need to reference it multiple times in your CSS, you might consider using a single image map instead you can then crop your single images from (see CSS Sprites).

Kaylakayle

It just means that you should have one css class on an element for referencing the background image, and another css class for referencing the offsets into that image to use for that element. – Sf

you should have NO classes on the elements that describe how material is presented - those classes should be well-named and semantic (this is not always possible, but good to shoot for) If multiple elements use the same image, and you would like to encode that image in the CSS, just leave the image out of the declarations, and use a later css rule to declare and embed the image for multiple selectors/classes. – Tia

If you're shooting for semantic classes and also want the image data just once, you can have a separate style which lists all the relevant selectors, and then offsets defined in per-selector styles. Of course, for a very small image in a lot of places, the selector list might be bigger than the data... – Medarda

In order to avoid multiple classes and only specify a sprite sheet once, you could use an attribute selector: [emoji] {background-image: url(data:image/png;base64,qwedfcsfrtgyu/=);} [emoji=happy] {background-position: -20px 0px;} – Unsteel

Answer 4

One of the things I would suggest is to have two separate stylesheets: One with your regular style definitions and another one that contains your images in base64 encoding.

You have to include the base stylesheet before the image stylesheet of course.

This way you will assure that you're regular stylesheet is downloaded and applied as soon as possible to the document, yet at the same time you profit from reduced http-requests and other benefits data-uris give you.

Amero

I like this in theory. Can anyone think of any arguments against? – Mccauley

I was just Googling this myself to find out if it is a good idea and came here. In my case the images are all just UI stuff and I was thinking this would be a good idea. Not sure if it's better than using css sprites but I feel it is easier to manage if you do make changes in the future. Would love to know if anyone has anything against this? – Chungchungking

Answer 5

Base64 adds about 10% to the image size after GZipped but that outweighs the benefits when it comes to mobile. Since there is a overall trend with responsive web design, it is highly recommended.

W3C also recommends this approach for mobile and if you use asset pipeline in rails, this is a default feature when compressing your css

http://www.w3.org/TR/mwabp/#bp-conserve-css-images

Devest

good point re mobile/responsive though I am not sure of the 10%, where do you get that data from? – Bradwell

This is correct. The slowest thing in any mobile device is the open/close of http connections. Minimizing them is recommended. – Vicinal

despite w3 results, in some test I did the size of images increased by ~25% :( – Kahlil

I guess it can raise up to 33% if it's just impossible to zip it. – Sprage

on mobile 10% is nothing compared to the creation of http connections – Vicinal

Without compression, base64 should consume 25% extra space, though I had a test PNG 523b → base64 710b (35.8%, wtf) → gz 560b (7.5%). Compression will always lower that since base64 only uses a small number of characters. Also consider HTTP header sizes. Try using pngquant to further compress your base image if you care about every byte. – Selfdiscipline

Answer 6

I disagree with the recommendation to create separate CSS files for non-editorial images.

Assuming the images are for UI purposes, it's presentation layer styling, and as mentioned above, if you're doing mobile UI's its definitely a good idea to keep all styling in a single file so it can be cached once.

Liebknecht

Answer 7

In my case it allows me to apply a CSS stylesheet without worrying about copying associated images, since they're already embedded inside.

Wines

Answer 8

I tried to create an online concept of CSS/HTML analyzer tool:

http://www.motobit.com/util/base64/css-images-to-base64.asp

It can:

• Download and parse HTML/CSS files, extract href/src/url elements
• Detect compression (gzip) and size data on the URL
• Compare original data size, base64 data size and gzipped base64 data size
• Convert the URL (image, font, css, ...) to a base64 data URI scheme.
• Count number of requests which can be spared by Data URIs

Comments/suggestions are welcome.

Antonin

Japeth

Answer 9

You can encode it in PHP :)

<img src="data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>">

Or display in our dynamic CSS.php file:

background: url("data:image/gif;base64,<?php echo base64_encode(file_get_contents("feed-icon.gif")); ?>");

1 That’s sort of a “quick-n-dirty” technique but it works. Here is another encoding method using fopen() instead of file_get_contents():

<?php // convert image to dataURL
$img_source = "feed-icon.gif"; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);
?>

Source

Coontie

Answer 10

Bringing a bit for users of Sublime Text 2, there is a plugin that gives the base64 code we load the images in the ST.

Called Image2base64: https://github.com/tm-minty/sublime-text-2-image2base64

PS: Never save this file generated by the plugin because it would overwrite the file and would destroy.

Euphemize

Answer 11

Thanks for the information here. I am finding this embedding useful and particularly for mobile especially with the embedded images' css file being cached.

To help make life easier, as my file editor(s) do not natively handle this, I made a couple of simple scripts for laptop/desktop editing work, share here in case they are any use to any one else. I have stuck with php as it is handling these things directly and very well.

Under Windows 8.1 say---

C:\Users\`your user name`\AppData\Roaming\Microsoft\Windows\SendTo

... there as an Administrator you can establish a shortcut to a batch file in your path. That batch file will call a php (cli) script.

You can then right click an image in file explorer, and SendTo the batchfile.

Ok Admiinstartor request, and wait for the black command shell windows to close.

Then just simply paste the result from clipboard in your into your text editor...

<img src="|">

or

 `background-image : url("|")` 

Following should be adaptable for other OS.

Batch file...

rem @echo 0ff
rem Puts 64 encoded version of a file on clipboard
php c:\utils\php\make64Encode.php %1

And with php.exe in your path, that calls a php (cli) script...

<?php 

function putClipboard($text){
 // Windows 8.1 workaround ...

  file_put_contents("output.txt", $text);

  exec("  clip < output.txt");

}


// somewhat based on http://perishablepress.com/php-encode-decode-data-urls/
// convert image to dataURL

$img_source = $argv[1]; // image path/name
$img_binary = fread(fopen($img_source, "r"), filesize($img_source));
$img_string = base64_encode($img_binary);

$finfo = finfo_open(FILEINFO_MIME_TYPE); 
$dataType = finfo_file($finfo, $img_source); 


$build = "data:" . $dataType . ";base64," . $img_string; 

putClipboard(trim($build));

?>

Briones

Answer 12

As far as I have researched,

Use : 1. When you are using an svg sprite. 2. When your images are of a lesser size (max 200mb).

Don't Use : 1. When you are bigger images. 2. Icons as svg's. As they are already good and gzipped after compression.

Prayer