SVG Icons: Separate Files, a Sprite or Inline?

A navigation bar or a feature list can easily carry twenty small icons. With SVG, there are three common ways to put them on a page: one file per icon in an <img>, one sprite file that holds every icon and is referenced with <use>, or the SVG code written directly into the HTML. How many requests and bytes does each way cost, and when are all the icons ready? We built the same row of twenty icons all three ways.

The test

We drew twenty simple stroke icons on a 24 × 24 grid, each a single <path>. We then built three versions of a page with a row of all twenty:

• twenty separate SVG files, each loaded with <img src="iN.svg" width="24" height="24">;
• one sprite file holding twenty <symbol> elements, used with <svg><use href="sprite.svg#iN"/></svg>;
• the twenty SVGs written inline in the HTML.

Each version was loaded five times in Chrome 155.0.8059.82 with a phone viewport, 150 ms latency, 1.6 Mbit/s and the CPU slowed four times. The local test server used HTTP/1.1 without compression. We recorded the HTML size, the icon requests, the bytes transferred for them, and when the last icon had downloaded. See our methodology.

Results

Separate files were the slowest: twenty requests, 6,362 bytes transferred, and the last icon arrived 883 ms after the page request. The twenty files together weighed only 2,802 bytes; the other 3,560 bytes were HTTP response headers, repeated twenty times. With six connections, the requests also had to queue in several rounds of the 150 ms latency.

The sprite needed one request of 2,717 bytes, and every icon was available at 362 ms.

Inline SVG needed no request at all. The icons arrived with the HTML, which grew from 1,506 to 3,755 bytes, so they could appear in the very first paint.

Trade-offs beyond this test

• Caching. A sprite or separate files are cached and reused on every page. Inline icons are sent again with each HTML page, which is cheap for a few simple icons and wasteful for many complex ones. Text compression shrinks repeated SVG markup well, as our SVG compression test shows.
• Styling. Inline SVG and <use> can inherit currentColor, so icons follow the text colour and hover states, including dark mode. An SVG in <img> is isolated from the page’s CSS.
• Origin. <use> only works with a sprite on the same origin as the page; a sprite on a CDN domain needs a workaround.
• Protocol. Under HTTP/2 or HTTP/3, the twenty separate requests share one connection and do not queue for connections, so the gap would be smaller than on our HTTP/1.1 server. Each request still carries its own headers.
• Accessibility. Decorative icons need alt="" in <img>, or aria-hidden="true" on an inline <svg>. Icons that carry meaning need a text alternative in either form.

Before choosing, run the icons through an optimiser; our SVGO test measured how much it removes. For when SVG beats PNG for icons at all, see our SVG vs PNG icon comparison.

Example: a sprite with currentColor

<!-- icons.svg -->
<svg xmlns="http://www.w3.org/2000/svg">
  <symbol id="search" viewBox="0 0 24 24">
    <path d="M10 4a6 6 0 1 0 0 12 6 6 0 0 0 0-12zm9 15-4.35-4.35"
          fill="none" stroke="currentColor" stroke-width="2"/>
  </symbol>
</svg>

<!-- in the page -->
<svg width="24" height="24" aria-hidden="true"><use href="/icons.svg#search"/></svg>

Practical conclusion

For twenty icons on a throttled phone profile, separate SVG files took twenty requests and arrived last, at 883 ms. A sprite took one request and was ready at 362 ms. Inline SVG took none and added 2.2 KB to the HTML. Inline a handful of icons that appear above the fold, use a sprite for larger sets used across the site, and avoid one file per icon.

Limitations

Very simple icons, a local HTTP/1.1 server without compression, Chrome only, five loads per version. Detailed icons, HTTP/2 and compression would change the absolute numbers. Repeat visits with a cached sprite were not measured.

Data and files

Download svg-icon-methods.csv (3 rows, 0.2 KB) · Method: testing methodology.