The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Inline SVG markup is part of the HTML document, so it is not cached as a separate image or HTTP subresource. The HTML itself may be cached, but to cache and reuse an SVG independently—especially across pages—serve it as an external file or sprite with suitable HTTP cache headers.
How caching differs for inline and external SVG
When an SVG is written directly into a page’s HTML, the browser receives it as part of that HTML response. There is no separate SVG request for the browser or an intermediary cache to store and reuse independently. If the HTML is served from cache, the inline markup comes along with that document; that is different from caching an SVG file as its own resource.
An external SVG has its own URL and HTTP response. The browser can reuse a cached copy on later requests when the response’s cache policy permits it, and shared caches may reuse it where applicable. HTTP caching can speed up repeat visits, but the outcome depends on the headers and whether the URL identifies the same content. See Chrome’s long-cache-lifetime guidance and MDN’s HTTP caching guide.
Which SVG delivery method should you choose?
| Pattern | Independent caching and reuse | HTML size and requests | Styling and interaction | Best fit |
|---|---|---|---|---|
| Inline SVG markup | No separate SVG resource to cache; it is delivered with the HTML. | Adds markup to the HTML; does not require a separate SVG request. | Direct access to SVG elements makes page-level CSS and DOM interaction practical. | A one-off graphic or icon that needs page-specific styling or DOM behavior. |
| External same-origin SVG file or sprite | Can be cached as its own resource and reused across pages, subject to response headers. | Requires a separate request unless already cached; keeps SVG markup out of each HTML response. | Can be referenced with SVG <use>; it is not the same as embedding each graphic’s markup directly in the document. |
Repeated logos or icons, particularly when reuse and independent caching matter. |
SVG in a data: URL |
Not independently cached as a separate resource. | Can increase the containing HTML or stylesheet size. | Do not use a data: URL as the target of SVG <use> in new work; support has been removed or dropped in browsers. |
Generally avoid as a substitute for an external, reusable SVG resource. |
There is no universal speed winner. An inline icon avoids a separate request but makes the HTML larger; an external icon adds a request unless the asset is already cached, and can be reused. Measure transfer size, request count and latency on the devices and networks that matter to your site. web.dev’s discussion of data URIs notes they cannot be cached as separate resources, can considerably increase HTML size and may be slower on mobile.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
When inline SVG is the better choice
Use inline markup when a graphic is unique to a page or needs direct integration with the page’s CSS, DOM events or state. It can also be useful when avoiding a separate request is more important than reusing the same asset elsewhere. Remember that placing the same markup on multiple pages repeats it in each HTML response.
When an external SVG or sprite is better
For a logo or icon used across multiple pages, an external same-origin file or sprite gives the asset its own URL and lets the browser reuse it under the configured cache policy. Chrome’s guidance describes same-origin external SVG files used with <use> as an alternative to data URLs: Migrate away from data URLs in SVG use.
External-file <use> is widely supported, while <use> pointing to a data: URL is not, according to MDN’s SVG linking guide. For a reusable sprite, reference a same-origin SVG file rather than relying on a data URL.
How to set cache headers without serving stale icons
Choose the cache policy based on how the SVG changes. For a static asset whose URL changes whenever its contents change, a long lifetime lets the browser keep using the cached file without checking on every visit. Chrome Developers’ 2019 Lighthouse documentation gives 31536000 seconds—one year—as an example of Cache-Control: max-age for immutable static assets. Treat that as an example, not a requirement: use it with a versioned or content-hashed URL and update that URL when the SVG changes.
For content that may change at the same URL, use validation rather than an extended immutable lifetime. With no-cache, a stored response must be revalidated before reuse; validators such as ETag or Last-Modified can let the server confirm whether the cached copy remains current. For user-specific responses, add private so shared caches do not store them. MDN explains these directives and validation.
no-store is different: it tells caches not to store the response, giving up browser-caching benefits. It is not a general fix for stale icons; MDN advises against using it liberally. For static SVGs, versioned URLs plus a long lifetime usually provide a clearer update mechanism than disabling storage.
How to cache SVGs for an offline app
A service worker can precache or runtime-cache external SVG assets, depending on when the app needs them. Workbox notes that SVGs are relatively safe to precache because one vector asset can be used at any pixel density, but assets not needed by every user should generally be runtime-cached instead. See Workbox’s precaching guidance. This applies to separately fetched assets; inline SVG remains part of the HTML response.
Quick Recap
Practical decision checklist
- Choose inline markup for a one-off graphic that needs direct CSS styling or DOM interaction.
- Choose an external same-origin SVG or sprite for repeated assets that should be reused and cached separately.
- Do not use
data:URLs as SVG<use>targets for new work; browser support is not dependable. - For stable assets, pair long cache lifetimes with versioned or content-hashed URLs that change when the file changes.
- For changing or personalized responses, use revalidation and appropriate privacy directives rather than an immutable lifetime.
- For offline behavior, select service-worker precaching or runtime caching based on whether every user needs the asset.
- Compare transfer size, request count and latency in the target environment instead of assuming one delivery pattern is always faster.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
