There are a bunch of tools available:
https://github.com/nzakas/cssembed
https://github.com/cloudhead/less.js/wiki/Include-Data-URI-B...
http://compass-style.org/reference/compass/helpers/inline-da...
There are a bunch of tools available:
https://github.com/nzakas/cssembed
https://github.com/cloudhead/less.js/wiki/Include-Data-URI-B...
http://compass-style.org/reference/compass/helpers/inline-da...
With data uris, you're putting the image data in your css file. This creates two performance differences to images.
Firstly, the user will download the image data even if it isn't used on the page, an external image is only downloaded if it's element is present & visible.
Secondly & more importantly, browsers completely block rendering while CSS downloads (with the exception of Opera, which unblocks after about 3 seconds), CSS does not render progressively. A 10k CSS file with 60k of imagery will load slower than a 70k CSS file due to HTTP overhead, although it'll be perceived faster as the user sees things happening after 10k rather than looking at a blank screen until the full 70k has downloaded. Small numbers, but noticeable on flakey wi-fi and mobile connections.
In terms of image size, when you base64 encode an image you're using 8 bits of data to represent 6. Gzip deals with a lot of this, but it's still an extra ~10% per image. That's compared to separate images, with a sprite image you get further benefits by sharing a PNG palette and compression across all sprites.
Neither sprites or data uris are the "correct solution" in all situations, it should be considered on a case by case basis. Sprite Cow itself uses both techniques, the toolbar icons are in a sprite, some smaller tiling assets are data uris.
In general, this is a process best curated manually, with a maximum on converted file sizes and hand-picking images that are "must-haves" for the initial page load.