Before HTTP/2, every image request was expensive, so developers combined icons into one big image (a sprite) and showed parts of it with background-position. Data URIs solve the same problem differently: the icons travel inside the CSS file.
Comparison
| CSS sprite | Base64 data URI | Inline SVG / SVG data URI | |
|---|---|---|---|
| Requests | 1 for all icons | 0 (inside CSS) | 0 |
| Size overhead | none | +33% before compression | small, text compresses well |
| Caching | sprite cached separately | cached with the CSS | with the HTML or CSS |
| Update one icon | regenerate the sprite | change one rule | change one rule |
| Retina / scaling | needs 2× sprite | needs 2× image | scales perfectly |
Recommendations for today
- Use SVG for icons. Either as inline
<svg>elements or URL-encoded SVG data URIs. They are tiny, sharp at any size and stylable. - Use Base64 data URIs for very small raster images that are needed for the first render: a placeholder blur, a tiny pattern, a cursor.
- Avoid sprites in new projects. HTTP/2 multiplexing makes many small requests cheap, and sprites complicate maintenance.
- Always serve CSS compressed. Gzip and Brotli reclaim most of the Base64 overhead — see the gzip analysis.
Convert existing stylesheets automatically with the CSS Data URI Converter.
Comments (0)
Questions, ideas or a bug in “CSS sprites vs data URIs”? Leave a comment, rate the tool, or reply to others.
No comments yet. Be the first to share your feedback!