Favicon Sizes and Formats: Specify Every Icon Before Launch

Executive Summary

Ordering favicons is a set of surface decisions, not one export. A tab icon, a search-result icon, an iPhone home-screen shortcut and an installed web app are governed by different documents, different file formats and different pass criteria. This report, current as of 2 November 2026, converts those documents into a one-page specification with separate designer and build-owner duties.

Google's search rules are narrower than browser support. Google Search supports BMP, GIF, ICO, PNG, JPEG, PPM and TIFF favicon files ^[1], requires a square image of at least 8x8 px ^[1], and recommends one larger than 48x48 px ^[1]. SVG is absent from that list, even though Safari 26 added SVG icon support in its own interface ^{[2] [3]}. Google also supports one favicon per hostname ^[1] and does not guarantee display even when every guideline is met ^[1].

Mask and installable-app work is an optional branch. MDN defines the maskable safe zone as a circle with a diameter of 80% of the icon's minimum dimension ^[4], and the W3C draft states the same geometry as a radius of 2/5 ^[5]. For a 512x512 icon that is a radius of 204.8 px and a diameter of 409.6 px, but a centered square must be no larger than about 289.6 px to fit inside that circle (illustrative geometry, not a browser measurement). Chromium's installability guidance asks for 192x192 and 512x512 icons (Source: web.dev) ^[6], which does not apply to ordinary tabs.

Apple sizing needs a device test, not a universal number. The only Apple document that names sizes is archived and defers to current design guidance for recommendations ^[7], while WebKit has reported that apple-touch-icon takes precedence over manifest icons ^[8] and later posts describe manifest icons as used when defined ^[9]. Treat any single Apple size as a convention to be verified on a named device.

The practical output is a split between artwork delivery (a simplified mark, light and dark variants, an opaque mask-safe master) and installation evidence (the tags and files actually published, the response for each file, and dated screenshots on named browsers). Cache behavior is a documented reason for a wrong-looking result: Google says recrawling can take several days to several weeks ^[1], and one practitioner reports Safari caching favicons aggressively ^[10].

Introduction and Background

A founder approving a website launch usually receives one question from the builder: "send the favicon." That sentence hides at least four deliverables. The mark that reads in a browser tab is rarely the full logo. The file Google Search will fetch is limited to a specific list of formats. The icon an iPhone user saves to the home screen follows Apple's platform rules. The icon for an installed web app, if the project wants one at all, follows a separate manifest specification. A complete vector logo does not prove that any of these four outputs is legible, correctly masked, contrast-safe in both browser themes or even being served.

This report is written for startup and software-as-a-service marketing leads, founders, and agency project managers who coordinate an external logo designer with a web builder. It starts with an ordinary marketing site and keeps installable web app requirements in a clearly labeled optional branch. It is not a framework tutorial, not an app-store icon guide, and not a bulk-icon generator review. Its distinct contribution is a surface-by-surface delivery and visual acceptance sheet.

Several good references already exist. A maintained engineering article from Evil Martians, titled "How to Favicon in 2026" despite a 2021 URL path, recommends a reduced file set and states that a minimum set can work with just three PNG images ^[11]. Chris Coyier's 2021 CSS-Tricks article adopts that recipe and explains his own implementation choices ^[12]. A blog post from SitePatent, a website-listing service that also publishes a favicon how-to, offers the opinion that three files cover most websites ^[13]. This report does not promise a magic universal file count: the Evil Martians title, its URL slug and its prose use different counts, and the right set depends on which surfaces the project selects.

The evidence base is limited in three ways. First, the W3C manifest specification is a Working Draft, not a final Recommendation ^[5]. Second, web.dev's adaptive-favicon article is a technique explanation (Source: web.dev) without a displayed date, not a current market-share measurement. Third, a 2021 practitioner report that Chrome loaded the ICO file instead of the SVG ^[10] is historical and is not a current compatibility fact; it is cited only to show why a device test belongs in acceptance. No traffic, conversion, performance or time-saving claims are made.

The report uses "requirement" for a rule a document states as mandatory in its scope, and "recommendation" for advice. Every rule carries its scope: Google Search, Chromium installability, Safari, or a content management system (CMS).

Key Changes That Affect Icon Scope

Five documented points explain why older "icon checklists" over-order or under-order files. Most are standing documentation rather than rule changes on a specific date, and Google's requirements are a separate list, not a change.

Safari now accepts SVG icons

WebKit's Safari 26.0 post says Safari now supports the SVG file format for icons everywhere icons appear ^[2], and Apple's release notes list "Added support for SVG icons" in the Browser section ^[3]. WebKit frames the benefit as vector scaling: developers rely on Safari to create rasterized icons at multiple sizes ^[14]. The sources do not say whether this covers apple-touch-icon links as well as ordinary favicon links, so that question belongs on the device-test list, not in the specification as a fact.

The caniuse feature page for SVG favicons makes the same hedged point from the compatibility side: SVG can be preferable for higher resolutions or larger icons ^[15], and the page calls favicon support a complicated topic ^[15]. This is why the specification below keeps an ICO or PNG next to an SVG.

Any website can become a web app on iOS

WebKit reports that in Safari 26 on iOS and iPadOS, every website added to the Home Screen opens as a web app by default ^[14], and Apple's release notes list support for any website to become a web app ^[3]. The Safari 26.0 post says there are zero requirements for this behavior ^[2]. For a marketing site, this widens the set of visitors who may see a home-screen icon without the project ever commissioning a progressive web app (PWA). It does not turn every launch into PWA work: the icon is still chosen through apple-touch-icon or manifest declarations the builder publishes.

Apple's current iPhone user guide adds a small but relevant fact: the Home Screen website icon appears only on the device where the user adds it ^[16]. A launch review therefore cannot assume that one tester's saved shortcut proves anything about another device.

Google Search favicon requirements form a separate list

Google's favicon page distinguishes a floor from a recommendation. The floor is a square image at least 8x8 px ^[1]; the recommendation is larger than 48x48 px so the icon looks good on various surfaces ^[1]. The format list excludes SVG. Wix's help page states a different-sounding vendor fact, that Google rescales a favicon to 16x16 px for search results ^[17]. Google's own page frames the matter as an 8x8 floor and a larger-than-48x48 recommendation, so the Wix number is best treated as a site-builder statement about its own output, not as Google's rule.

Builders now generate and theme icons

Webflow's help documentation says a single uploaded square image produces all favicon and touch icon sizes ^[18], and its May 2026 update note lists 32x32 and 48x48 favicons, 180x180 and 192x192 touch icons, and a 256x256 webclip ^[19]. It also offers a separately uploaded favicon optimized for dark backgrounds ^[18]. Automatic resizing is useful, but it means the builder's output must be inspected: the CMS decides which dimensions exist, so the acceptance sheet asks the builder to list the files actually returned, not the files the designer supplied.

Installability still requires 192px and 512px icons

Chrome's installability guidance on web.dev lists icons as a manifest requirement: the icons member "must include a 192px and a 512px icon" (Source: web.dev). An older Chrome developer-blog post mentioned possible future experiments with relaxing manifest requirements, but the current web.dev criteria are the ones to use for a launch sheet.

Surface-by-Surface Specification

Table 1 below maps each surface to the document that governs it, the artwork variant the designer must supply, the files the builder publishes, and whether a statement is a requirement or a recommendation. It deliberately does not end in a total file count.

Table 1 shows that the same logo is asked to do five different jobs under five different rule sets. The two statements most often merged are the Google row and the iPhone row: Google's list governs only Google Search, while Apple's sizes come from a different company's platform. The table also shows why a designer cannot satisfy every row by exporting a longer list of sizes; two rows (dark theme and installed app) need different artwork, not different pixel counts.

What the HTML standard fixes

The standard gives icon links no default type ^[20], so a type attribute is optional, and when several icons are equally appropriate, user agents must use the last one declared in tree order ^[20]. The practical consequence for an acceptance sheet is that link order is part of the specification: two correct files declared in a different order can produce a different tab icon. MDN says the "any" value means the icon is a vector that can scale to any size ^[22], and its glossary entry describes a typical favicon as 16 x 16 pixels in size ^[23], which is a description of the tab slot, not a recommendation for the source artwork.

SVG versus ICO

The decision is not either/or. SVG is the better master for the designer to deliver because it scales and can respond to a theme (Source: web.dev). ICO remains useful because it is a container: MDN notes that ICO files contain multiple raster icons optimized for different display sizes ^[24]. For search, only the raster side of the pair appears in Google's format list ^[1]. In Chrome's 2021 behavior, a practitioner found that the ICO was loaded instead of an SVG until the ICO link carried the "any" size keyword ^[10]; that was a 2021 observation, and a current device test, not the anecdote, decides whether it still applies.

Artwork Adaptations the Designer Supplies

The designer's deliverable is a short set of artwork variants, each tied to a surface. The full logo stays in the brand file. The favicon is a different drawing.

Choose a simplified mark for tiny display

A browser tab slot is described by MDN as typically 16 x 16 pixels ^[23]. A wordmark that is wide cannot fill that slot without shrinking its letters. This report's illustrative arithmetic (fictional example, no recognition score implied): a 380 x 90 unit wordmark scaled to fill a 16 px width has a letter band 3.8 px tall; scaled to 32 px wide it is 7.6 px tall. A square symbol can use the full slot instead.

(Hypothetical Example) A fictional analytics firm, "Harbor & Pine", has a wordmark with a small pine glyph in front of the letters. The designer is asked to supply a simplified mark: the pine glyph alone, thickened, on a single flat color. The annotated preview below is a text approximation of a 16 x 16 grid; a hash is a filled pixel and a dot is background.

Wordmark squeezed to 16 px wide      Simplified symbol at 16 px
(letter band about 4 px tall)        (full grid used)
................                     .......##.......
................                     ......####......
................                     .....######.....
................                     ....########....
.#.#.##.#.#.###.                     ...##########...
.###.#.#.##.#.#.                     ......####......
.#.#.##..#..###.                     .....######.....
................                     ....########....
................                     ...##########...
................                     ..############..
................                     ......####......
................                     ......####......
................                     ......####......
................                     ................
................                     ................
................                     ................

In the left preview the lettering has no recognizable letter shapes and most of the grid is empty; in the right preview the silhouette is readable without a caption. The preview is an illustration of the reasoning, not a measurement of recognition. The acceptance test still has to happen on a real display.

Designer duties for this variant:

• Deliver the simplified mark as vector artwork with the shape thickened and details removed.
• State which elements were dropped from the full logo, so the brand owner approves the reduction explicitly.
• Provide a flat single-color fallback in case a surface applies a monochrome treatment ^[24].
• Preview the mark at 16, 32 and 48 px on the actual background colors of the browser themes.

Light and dark visibility

WCAG 2.2 success criterion 1.4.11, Non-text Contrast, covers parts of graphics required to understand content ^[25]. The Understanding document says logos are exempt from the contrast requirements ^[25], with a limit: if a logo normally has sufficient contrast but is presented with insufficient contrast, the exemption does not apply ^[25]. The Understanding document does not address favicons by name, so this report does not treat WCAG as a favicon pass or fail rule. It is used as a practical design check: ask whether the mark remains distinguishable on both a light and a dark browser strip.

The technical route for theming is documented. MDN describes the prefers-color-scheme media feature as the way to detect that a user requested a light or dark theme ^[26], and web.dev shows that an SVG favicon can contain embedded CSS with media queries (Source: web.dev). The same article reports support in Firefox and Chromium-based browsers (Source: web.dev), a statement about one technique. A project that does not need theme-dependent colors can skip this variant, for example when the simplified mark has a built-in light outline or a mid-tone fill that reads on both strips.

Mask-safe geometry for home-screen and installed icons

When an operating system applies a mask (a circle, a rounded square or another shape), artwork outside the safe zone may be cropped. MDN advises an opaque background that fills the entire icon area ^[4]. Safari's 17.2 release post similarly asks for at least one opaque, full-bleed icon for macOS web apps ^[27]. The geometry has to be checked against a circle, not a square, which is demonstrated in the Data Analysis section below.

Implementation Considerations and Process Changes

Artwork delivery is only half of the job. The builder must show what was actually published, and a reviewer must see it on named browsers.

What the builder must identify

The builder owns the published tags, the files they point to, the HTTP responses, and the CMS behavior. For every icon, the evidence is:

• The exact link or manifest line as published in the live page source.
• The file URL, format and real pixel dimensions, since a declared size may differ from the actual image. The HTML standard defines sizes in raw pixels ^[20], and MDN recommends exact sizes for raster manifest icons ^[24].
• The HTTP status and content type returned for each icon URL.
• Crawlability: Google requires that the favicon and home page not be blocked by robots.txt or other means ^[1], and Googlebot-Image must be able to crawl the favicon file ^[1].
• Hostname scope: Google supports one favicon per site, where a site is defined by the hostname ^[1]. A marketing site, a documentation subdomain and an app subdomain need separate decisions.
• Stability: Google says the favicon URL must be stable ^[1], so versioned file names that change at every deploy are a reason to ask questions.

CMS fields deserve a specific look, because each platform transforms an upload differently; the vendor statements are compared in the Data Analysis section, and the acceptance sheet records the platform and the date of the help page the builder relied on.

Separate installed results from cache

A wrong-looking icon is not always a wrong output. Google says crawling after a change can take anywhere from several days to several weeks ^[1]. A practitioner's 2021 testing reported that Safari caches favicons aggressively and does not give an easy way to purge that cache ^[10], and that Safari never seems to want to let them go ^[10]. These are not current measurements; they are a reason to test with a fresh profile or a device that has never loaded the site, and to record "stale cache suspected" as a separate result from "wrong file served."

Apple home-screen evidence

The archived Apple document describes placing a PNG icon in the root document folder ^[7], and adding a sizes attribute to each apple-touch-icon link element to offer multiple icons for different device resolutions ^[7]. The same document defers to Apple's design guidance for current sizes ^[7]. MDN notes that iOS uses the nonstandard apple-touch-icon instead of the standard icon link ^[21].

Two WebKit statements need to be read together. In 2023, WebKit reported that apple-touch-icon takes precedence over manifest-declared icons ^[8], and that without any supplied icon, iOS would previously create an icon from a screenshot of the site ^[8]; the same post describes a newer monogram of the first letter of the site's name ^[8]. A June 2025 post says that icons defined in the manifest are used ^[9]. No Apple or WebKit source cited here states whether the 2023 precedence still holds in Safari 26. The correct response is a test on a named iOS version, with a screenshot, not a rule in the specification.

Acceptance sheet

Table 2 below is the acceptance sheet the builder and reviewer fill in. The second column is the environment that must be named for every screenshot. The sample row is fictional.

Table 2 deliberately separates three questions a single "done" tick conflates: whether the right file exists, whether the right file is served, and whether the result looks right in a named environment. A search row never has a visual pass in it, because Google says a favicon is not guaranteed to appear even when all guidelines are met ^[1]; the sheet grades only the technical conditions the owner can control.

Correction-request examples

Change requests are shorter and faster to resolve when they name a surface, an environment and a file.

• Tab, dark theme: "On the dark tab strip in the named browser, the mark's dark outline disappears; please supply a light-outlined variant or a theme-aware SVG."
• iOS shortcut: "The saved shortcut shows a letter monogram, not the logo; please confirm the apple-touch-icon link is present and returns an image."
• Installed app: "The maskable icon has artwork at the corners; move it inside the centered circle."

Optional Branch: Installable Web App

Skip this section if the project is an ordinary marketing site and no one has asked for installation. A web app manifest is a JSON file that describes an installable application, and its icons member lists images with sizes and purposes.

Web app manifest icon sizes

Chromium's guidance on web.dev says a manifest must provide at least a 192x192 and a 512x512 icon (Source: web.dev), and MDN's installability page says Chromium-based browsers require the icons member to contain a 192px and a 512px icon ^[6]. Chrome automatically scales the icons to fit the device (Source: web.dev). This guidance is scoped to Chromium installability; the same MDN page says Firefox does not support installing PWAs using a manifest file ^[6]. It is not a rule for tab icons or for Google Search.

MDN recommends exact sizes for raster formats such as PNG ^[24] and states that the source icon should be at least 1024x1024 pixels, or scalable to that size ^[4]. It also advises creating PNG versions as well, to support all operating systems and small sizes ^[4]. As an example of operating-system variation, MDN notes that Windows can display an app icon as a 44x44 pixel image in the taskbar ^[4].

Purposes: any, maskable, monochrome

The "any" purpose is the default, meaning the icon can be used in any context ^[24]. The W3C draft says the user agent is free to display such an icon where no purpose is required ^[5]. A maskable icon is, in the W3C draft's words, designed with icon masks and a safe zone in mind ^[5]. A monochrome icon has its color discarded and only the alpha data used ^[5]. The draft status matters: this is a Working Draft published by the Web Applications Working Group ^[5], so the draft's wording is not evidence that every browser implements every purpose. A user agent may also ignore media types it does not support ^[28].

The maskable icon safe zone

web.dev says the important parts of a maskable icon must lie within a circular area in the center (Source: web.dev), with a radius equal to 40% of the icon width (Source: web.dev). The W3C draft expresses the same geometry as a centrally positioned circle with radius 2/5 ^[5], and MDN as a circle whose diameter is 80% of the minimum dimension ^[4]. An Evil Martians guide gives a rounded 409 px central circle for a 512 px icon ^[11]; that figure is a rounding of 409.6 and is used here only as agreement with the arithmetic below, not as an independent standard.

Safari path

Safari's behavior differs from Chromium's. WebKit's Safari 17.2 post recommends at least one opaque, full-bleed icon for macOS web apps ^[27]. A project that chooses this branch should list Chromium and Safari as separate rows in Table 2 and name the versions tested.

Data Analysis and Evidence

This section holds the numerical and documentary core: the illustrative safe-zone geometry, a comparison of CMS statements, and a list of open discrepancies. The geometry is original arithmetic from the published definitions, not a real-browser measurement.

Safe-zone geometry by icon size

The documents define the safe zone as a circle with radius 40% of the icon edge ^[5] (Source: web.dev). Table 3 below converts that into pixel values for three source sizes. The "largest centered square" column multiplies the radius by the square root of 2, which is the side of the biggest square whose corners lie on the circle.

Table 3 contains the central caution of the mask section: a 409.6 px square is not safe in a 512 px icon, because the safe region is a circle with that diameter, not a square. A centered square whose corners carry artwork must be no larger than about 289.6 px on a side. The circle covers roughly half of the canvas area (pi x 0.4 squared is about 0.503), so designers who fill the canvas with a logo are likely to lose edge content on a circular mask.

(Hypothetical Example) Two fictional artworks on a 512 x 512 maskable master. A wordmark 380 px wide and 90 px tall, centered, has a farthest corner at about 195.3 px from the center, which is inside the 204.8 px radius by about 9.5 px; it passes the geometric test. A square symbol 300 px on a side, centered, has its farthest corner at about 212.1 px, which is outside the radius by about 7.3 px; it passes only if the corners are empty, as with a circular glyph. A 400 px square symbol has a corner distance of about 282.8 px and fails by a wide margin even though it sits inside the 409.6 px diameter. These checks prove only geometry. They do not show that a real mask shape will behave this way, and passing the circle test says nothing about legibility. The wordmark, for instance, passes the circle but is the artwork least likely to read at tab size, as the earlier 3.8 px arithmetic shows.

CMS statements compared

The platforms below publish different inputs for what looks like one task. All figures are vendor statements about their own product, as read on 2 November 2026 unless a date is shown.

• WordPress documents a site icon at least 512 px wide, with PNG recommended ^[29]; its page shows a last-updated date of 25 April 2025.
• Shopify says the ideal favicon is 16x16 or 32x32 pixels ^[30].
• Squarespace recommends uploading between 100px and 300px square ^[31]; the page shows an update date of 5 August 2026.
• Wix requires a multiple of 48 px square ^[17], unless the file is an SVG ^[17].
• Webflow generates 32x32, 48x48, 180x180, 192x192 and 256x256 assets from one square upload ^[19]; the update note says it launched on May 5, 2026 ^[19].

The spread, from 16 px to 512 px recommended uploads, shows why a single "correct size" does not exist at the CMS layer. What the designer delivers should be a square master large enough for the largest platform, with the builder owning the confirmation of what the platform actually generates.

Source discrepancies and open items

• File counts: the Evil Martians title, URL slug and prose disagree (the title, the URL slug and the prose each use a different count), so no count is adopted.
• Dated browser-share and safe-circle figures: not repeated as standards.
• Apple sizes: the only Apple page naming sizes is archived and shows 152, 167 and 180 pixel examples; it defers to current guidance ^[7]. The archived Apple page gives no current sizes and defers to design guidance; no current Apple size list was found among the sources cited here, so test on a device.
• Apple icon precedence: 2023 precedence of apple-touch-icon ^[8] versus 2025 statement about manifest icons ^[9]; unresolved in the cited sources.
• Google page date: Google's page shows no last-updated date, so no change date is asserted.

Implications and Future Directions

For a launch owner, the practical implication is a change of question. "Which sizes do we need?" becomes "Which surfaces do we need to look right, and who proves it?" The specification sheet answers that with a small number of decisions: whether the project needs search identity, whether it expects home-screen shortcuts, whether it will support theme-aware icons, and whether it wants an installable app. Each "no" removes artwork and files from the order.

Two developments could change the sheet. First, if the W3C manifest draft advances beyond Working Draft status ^[5], its purposes and safe zone may be implemented more uniformly. Second, SVG support in Safari 26 ^[2] may reduce the raster files a project needs on Apple platforms, but Google's list is a separate constraint ^[1]. A reviewer should revisit the sheet at each of these points and date every re-test.

There is a limit to what a favicon acceptance sheet can prove. It does not certify a site, a PWA, or the quality of a search result listing. Google states that a favicon is not guaranteed to appear in results ^[1]; the sheet therefore never promises it. Open questions that need first-hand tests include Safari 26's treatment of SVG in apple-touch-icon links, current iOS handling of transparent areas, and how particular CMS platforms resample uploads.

Frequently Asked Questions (FAQs)

What favicon sizes are needed for all devices?

There is no single list for all devices. Google Search needs a square supported-format file of at least 8x8 px, with larger than 48x48 px recommended ^[1]. Chromium installability asks for 192x192 and 512x512 manifest icons (Source: web.dev). Apple sizes need a device test, since the only Apple document naming sizes is archived ^[7]. Use Table 1 to decide which rows apply.

What size is an Apple touch icon?

The archived Apple document gives 152, 167 and 180 pixel examples and defers to current guidance ^[7]. Practitioner and builder sources use 180x180 ^{[11] [19]}. Treat 180x180 as a common convention, supply it as an opaque PNG, and verify on a named iOS version.

What is the maskable icon safe zone?

A centered circle with radius 40% of the icon edge ^[5], which is a diameter of 80% ^[4]. For 512 px, a radius of 204.8 px.

How is a favicon created from a logo?

Do not shrink the logo. Have the designer draw a simplified mark, preview it at 16, 32 and 48 px on light and dark strips, and deliver a square vector master with the approved reductions listed. Then have the builder export or let the CMS generate files, and record what was served.

What belongs on a pre-launch favicon checklist?

• Surfaces chosen in Table 1, with "no" decisions recorded.
• Simplified mark approved by the brand owner.
• Light and dark checks on named browsers.
• Live source captured: link tags, file URLs, real dimensions, status codes.
• Google conditions checked: format, square, robots.txt, hostname.
• Apple shortcut tested on a named device.
• Optional app branch only if requested: manifest, opaque maskable master, circle test.
• Cache separated from output errors, with dates on every screenshot.

Conclusion

A favicon order is complete when each selected surface has an artwork variant, a published file and a dated result on a named environment. The documents behind those surfaces differ in scope: Google Search publishes a format list that excludes SVG and a size floor and recommendation ^[1]; Safari 26 now accepts SVG icons ^[3]; Chromium installability uses 192 and 512 pixel manifest icons (Source: web.dev); and the mask safe zone is a circle of radius 40% of the edge ^[5], of which the 512 px case is 204.8 px.

The split between artwork delivery and installation evidence keeps responsibilities clear. The designer owns the simplified mark and the mask-safe master; the builder owns what the live site returns; the reviewer owns the visual verdict on a named browser and operating system. Search appearance remains outside any acceptance guarantee, and Apple sizing and precedence remain items to verify on a device. A launch that carries Table 1 and Table 2 can state precisely what was supplied, what was published and what was seen, without claiming more than the evidence supports.