SVG vs PNG vs ICO vs ICNS vs WebP — when to use which

Picking an image format is not a question of which one is "best." It is a question of which format serves the job: a UI icon that themes with currentColor has completely different requirements from a macOS app bundle submission or a favicon that must render at 16 px in a browser tab. This guide maps each format to the jobs it wins, the jobs it loses, and the traps that catch developers in real packaging pipelines.

The five at a glance

SVG

SVG is the right answer for almost every UI icon and logo. Because it is an XML description of shapes rather than a grid of pixels, it scales to any size without blurring, recolors instantly via CSS, and weighs almost nothing for typical glyphs.

The key production win: a single SVG file does the work of four or five raster exports. Inline it, reference it as an <img>, or pipe it into a component — the icon is always crisp on any DPI, from a 13-inch laptop to a 4K monitor.

SVG loses when the content is photographic or has depth effects that would need thousands of paths to express. It also loses in environments that explicitly block inline SVG (some CMS sanitizers, email clients) or in packaging pipelines that need a fixed-pixel artifact (Windows .ico, macOS .icns).

SVG gotchas

• Sanitize exports. Graphic tools embed <metadata>, editor-specific namespaces, and stray id attributes. Strip them before shipping — they bloat the file and can interfere with CSS scoping.
• Use currentColor, not hex. Hard-coding a fill means the icon cannot theme. See Themeable icons with currentColor for the full theming approach.
• No embedded rasters. An SVG that <image>-references a PNG is not scalable or themeable. It is just a very heavy PNG with extra steps.
• viewBox consistency. Mix sizes across a set and your stroke weights render differently. Pick one coordinate space — 0 0 24 24 is the standard — and stay there.

PNG

PNG is lossless raster with a full 8-bit alpha channel. It is the right choice when you need to preserve exact pixels: app store submission tiles, screenshots, print-resolution exports, and any raster artifact that must look identical to what you authored.

It is also the safe fallback for environments that cannot consume SVG or WebP. Every browser, every OS, every image-processing library handles PNG without question.

The practical downside is payload. PNG compresses losslessly, so a 512 × 512 RGBA PNG is significantly larger than an equivalent WebP at the same quality. At small UI sizes this rarely matters, but at high resolutions — app store tiles, splash screens, preview thumbnails — switching to WebP for web delivery can cut transfer size meaningfully.

PNG also does not scale up gracefully. A raster drawn at 48 × 48 displayed at 96 × 96 is just a blurry 48 × 48. For anything that must render across DPI densities, you either export multiple resolutions (@1x, @2x, @3x) or you use SVG in the first place.

WebP

WebP is a modern raster format developed by Google that supports four modes: lossy compression, lossless compression, transparency (8-bit alpha in both modes), and animation. Its main value proposition is smaller files at comparable visual quality compared to PNG (lossless) or JPEG (lossy).

As of 2026, WebP has over 96% global browser support across Chrome, Edge, Firefox, Safari 14+, and Opera. Internet Explorer never supported it.

The critical framing for icon work: WebP is a delivery format, not an icon container. You use it to serve web images efficiently — hero images, product photos, raster UI assets in PWAs — but you do not submit a WebP to the Windows or macOS packaging pipeline. Those pipelines expect ICO or ICNS respectively.

Animated WebP is a capable GIF replacement for short UI motion with better color depth and alpha support, but if your animation is a simple icon state change, CSS or SMIL on an SVG is lighter and more accessible.

A few legacy-tooling caveats remain: some image-processing pipelines (older PHP GD builds, certain CMSs, native macOS Preview versions before Monterey) handle WebP inconsistently. When you serve WebP on the web, always provide a PNG fallback via <picture> — see the snippet in One source, many targets below.

ICO

ICO is a container format that bundles multiple raster images at different resolutions into a single file. The operating system or browser picks the closest size for the rendering context. This is why a single favicon.ico can look right at 16 × 16 in a browser tab and at 32 × 32 in a Windows taskbar pin.

The maximum supported image dimension inside an ICO file is 256 × 256 pixels. Sizes above 256 px are not supported; for Windows app icons shown in high-DPI File Explorer or on the desktop, 256 × 256 is the ceiling.

ICO realities

A well-built ICO for Windows app distribution typically contains: 16 × 16, 24 × 24, 32 × 32, 48 × 48, 64 × 64, 128 × 128, and 256 × 256 — all in 32-bit RGBA. A favicon-only ICO for web use can get away with just 16 × 16 and 32 × 32, because the SVG favicon covers modern browsers.

Entries at 256 × 256 and sometimes 128 × 128 are typically stored as PNG-compressed data inside the ICO container rather than raw BMP bitmaps. PNG-compressed ICO entries dramatically reduce file size for large images — a 256 × 256 PNG-compressed entry is roughly 10–30 KB versus over 300 KB as a raw 32-bit bitmap.

The complete modern favicon family combines a scalable SVG, a small .ico fallback for old browsers and OS surfaces, an Apple touch icon PNG, and a web manifest for PWA icons:

<!-- Scalable SVG: used by modern browsers, pinned tabs, etc. -->
<link rel="icon" type="image/svg+xml" href="/favicon.svg">

<!-- ICO fallback: covers IE, older Edge, and OS-level pin targets -->
<link rel="icon" type="image/x-icon" href="/favicon.ico" sizes="32x32">

<!-- Apple touch icon: Home Screen icon on iOS/iPadOS -->
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">

<!-- Web app manifest: PWA icons (192 and 512 at minimum) -->
<link rel="manifest" href="/site.webmanifest">

The .ico file here contains 16 × 16 and 32 × 32 entries. The scalable SVG handles all modern browser contexts; the .ico is purely a fallback.

ICNS

ICNS is Apple's icon container format for macOS app bundles. Like ICO, it holds multiple resolutions in a single file — but the size set goes significantly higher, and it includes Retina (@2x) variants alongside standard (@1x) sizes.

A complete ICNS file contains 10 images: @1x and @2x pairs of 16 pt, 32 pt, 128 pt, 256 pt, and 512 pt — which means actual pixel dimensions spanning 16 × 16 through 1024 × 1024 (512 pt at @2x = 1024 px). The 1024 × 1024 entry is mandatory for App Store submission and is used for Finder preview icons on high-resolution displays.

Starting with macOS Sequoia, the system applies rounded corners automatically to app icons in Finder and the Dock. Export a square icon and let the OS handle the rounding — do not bake the radius into your asset.

The standard toolchain on macOS is iconutil: organize your PNGs into a .iconset folder with filenames following the pattern icon_16x16.png, icon_16x16@2x.png, ... icon_512x512@2x.png, then run:

iconutil -c icns MyApp.iconset

On non-macOS systems, tools including IconWorkshop handle the ICNS packaging from your source artwork without needing Xcode or iconutil.

Choosing in practice

The decision almost always comes down to target platform and rendering context:

• Need a UI icon that themes, scales, and has no performance overhead? SVG.
• Shipping a Windows .exe or installer? ICO with the full 16–256 size set.
• Building a macOS .app bundle? ICNS with all 10 @1x/@2x entries.
• Adding a favicon to a website? SVG + .ico fallback (a 32 × 32 ICO covers legacy browsers and OS pin surfaces).
• Serving high-quality photos or raster UI art on the web? WebP with a PNG fallback via <picture>.
• Need a raster artifact for app store tiles, print, or a pipeline that cannot consume SVG or WebP? PNG.
• Creating a short animated loop in a web page? Animated WebP or SVG/CSS — not GIF.

One source, many targets

The right production model is to author once — a high-resolution SVG or a large (1024 × 1024) master PNG — and then generate every format and size from that single source. Doing it any other way means re-drawing glyphs for each target and accumulating inconsistencies.

A few export gotchas that bite real pipelines:

Color profiles. A PNG exported from a design tool with an embedded ICC profile can look different from the same file viewed on a system that ignores the profile. Strip profiles from web-delivery PNGs and WebP; keep them in print-bound files. For icon containers (ICO, ICNS), use sRGB throughout.

Premultiplied alpha. Some compositors expect straight alpha, others premultiplied. Feeding the wrong kind into a Windows ICO pipeline can produce darkened halos around semi-transparent edges at small sizes. Export 32-bit RGBA as straight alpha from your tool, and verify the final .ico at 16 × 16 and 32 × 32 before shipping.

Hinting at small sizes. At 16 × 16 and 24 × 24, anti-aliased strokes from a scaled-down 512 px master often look muddy. Providing manually-hinted or pixel-snapped variants for the two smallest ICO entries prevents blurriness on standard-DPI screens.

Generating @2x and @3x for web raster. When you must use PNG or WebP for web icons (for instance, an Open Graph image or a PWA splash screen), generate the @2x and @3x versions from the same source, not by upscaling the @1x output.

The <picture> element is the correct way to serve WebP with a PNG fallback — it gives browsers a choice without JavaScript:

<picture>
  <!-- Modern browsers: use WebP for smaller payload -->
  <source type="image/webp" srcset="/img/app-icon-192.webp 1x, /img/app-icon-384.webp 2x">
  <!-- Fallback: PNG for older browsers and tools that don't handle WebP -->
  <img src="/img/app-icon-192.png"
       srcset="/img/app-icon-192.png 1x, /img/app-icon-384.png 2x"
       width="192" height="192" alt="App icon">
</picture>

For SVG theming in the context of dark mode — which affects how your icon colors read on OS-level surfaces as well as web — see Themeable icons with currentColor & dark mode.

Keeping all formats in sync manually across design revisions is where real teams lose time. The practical answer is a pipeline where the master SVG or high-res PNG is the only file you touch, and every ICO, ICNS, WebP, and PNG size is regenerated from it on each release.