How Android Chrome scales down icons

10 min read

First published on 13 May 2016 and revised since. The original post made two points: declare a large manifest icon so Chrome has good pixels to scale down, and keep the important artwork away from the edges because the launcher may mask the icon. Both still hold. What has changed is the vocabulary around them — in particular the web app manifest’s maskable purpose, which turned the second point from a rule of thumb into an explicit contract. This version keeps the 2016 advice and puts it in today’s terms.

When a visitor adds your site to an Android home screen, the icon on that screen is rarely displayed at exactly the size of any file you shipped. Chrome reads your web app manifest, chooses an icon it considers suitable for the job, and the system scales that image to the slot the launcher gives it. So the practical question behind the original post is unchanged: if your icon is going to be scaled anyway, what should you supply so the scaled result still looks like your logo?

What happens, step by step

  1. You declare icons in the manifest. The page links site.webmanifest, and the manifest lists PNG icons with their real src, sizes, type and purpose. Browsers trust those declarations when choosing a file, so a 192x192 file described as 512x512 does not become sharper — it just becomes mislabelled.
  2. Chrome picks a suitable icon for the context. A home-screen shortcut, an install dialog and a splash screen do not all need the same number of pixels, and a maskable icon is not interchangeable with an any icon. The exact choice depends on the declared sizes and purposes and on the device, which is why you declare the standard sizes honestly rather than trying to outguess one phone.
  3. The chosen image is scaled to fit. On many devices the launcher then displays that scaled image inside its own shape — a circle on one phone, a squircle or rounded square on another. That mask belongs to the launcher, not to your file, and it can change when the user changes launcher or theme.

Two different operations are happening here, and confusing them causes most Android icon bugs. Scaling changes how many pixels the image has. Masking changes which of those pixels are visible at all. A perfectly sharp 512x512 icon can still lose its corners to a circular mask; a perfectly safe, centred logo can still look soft if it was scaled up from a tiny source. You have to design for both.

Why the 2016 advice was “ship large and let it scale down”

In 2016, Android phones already came in a wide range of screen densities, and they still do. The launcher might need your icon at a size you never exported. Scaling a larger image down to that size generally gives the renderer more real detail to work from than scaling a smaller image up: downscaling averages genuine information away, while upscaling has to invent pixels that were never in the source, which reads as blur.

That is why the standard manifest pair has survived every change since this post was written:

  • 192x192 — the smaller home-screen size Chrome looks for.
  • 512x512 — the large size used where more pixels are needed, such as high-density displays and, in Chromium browsers, install and splash presentations. It is also the icon Chrome can scale down cleanly for smaller slots.

Declare both, generated from the same artwork with the same framing. You do not need to export a separate PNG for every Android density bucket the way a native app does; the manifest sizes plus the browser’s scaling cover that range. And generate the 512 from a source that is genuinely at least 512 pixels wide — or from your vector original. A 128x128 logo enlarged to 512x512 before upload is still a 128x128 logo wearing a bigger coat, and no amount of downscaling afterwards restores detail it never had.

What scaling down does not fix

The original post could be misread as “a 512 icon guarantees a sharp result”. It does not, and this is the part of the 2016 guidance most worth updating:

  • Fine detail disappears when it is scaled down. Thin strokes merge, small counters fill in and short words become texture. At home-screen size, nobody reads a tagline. Use the symbol, monogram or initial, and judge the icon at the size it will be used — not zoomed in on a monitor.
  • Low contrast stays low contrast. Scaling preserves your colours; it does not rescue a pale logo on a pale background.
  • Scaling cannot restore a small source. If the 512 file was upscaled from something tiny, the home-screen icon is a downscale of a blur, which is still a blur.
  • Scaling does not protect the corners. That is masking’s job, covered next. An edge-to-edge logo can be pixel-perfect and still come back from the launcher with its corners cut off.

In short: starting large is necessary, not sufficient. It buys the renderer good material; the design still has to survive being small.

The mask, and what “maskable” added after 2016

When this post was first written, “the launcher will probably crop your icon into a shape” was practical folklore. The manifest specification has since given that behaviour a name and a contract: an icon declared with "purpose": "maskable" promises it is designed to be masked, and in return a minimum safe zone is defined — a circle in the centre of the icon whose diameter is 80% of the icon’s width. Anything inside that circle should remain visible; anything outside it may be cut away by some launcher shape.

On a 512x512 maskable icon, that safe circle is about 410 pixels across, centred in the image. Two consequences follow:

  • The background must run to every edge. A maskable icon should be an opaque, full-bleed square — brand colour or pattern right out to the corners, with no transparency and no rounded corners of your own. The launcher cuts its shape out of that field; if the corners are transparent, whatever shows through is the launcher’s choice, not yours.
  • The logo must live inside the circle, not just inside the square. A square logo occupying 80% of the canvas still pokes all four corners outside the safe circle. As a rule of geometry, the largest square that fits inside the safe circle is about 57% of the canvas width, and wide wordmarks reach the circle’s edge even sooner. Round marks get the most room; text gets the least, which is another reason text rarely survives here.

maskable and any are different promises, so the careful setup declares them as separate artwork when the designs differ: the any icon can keep transparency and tighter framing for contexts without an aggressive mask, while the maskable version gets the full-bleed background and the smaller, centred mark. A single file can be declared "purpose": "any maskable", but only if that one design honestly satisfies both jobs — opaque to the edges and safe inside the circle. Declaring an ordinary transparent logo as maskable is exactly the failure the purpose exists to prevent: it comes back cropped, or small and padded onto a background you did not choose.

A manifest that gives Chrome something good to scale

Nothing about the manifest itself has become more complicated since 2016. It just has to tell the truth:

{
  "name": "Your site name",
  "short_name": "Your site",
  "icons": [
    { "src": "/web-app-manifest-192x192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" },
    { "src": "/web-app-manifest-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
    { "src": "/web-app-manifest-maskable-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ],
  "theme_color": "#ffffff",
  "background_color": "#ffffff",
  "display": "standalone"
}

Link it from the <head> of your pages with <link rel="manifest" href="/site.webmanifest" />, keep each icon’s sizes equal to the file’s real dimensions, and remember that relative icon paths resolve against the manifest’s URL, not the page’s. Set background_color to match the maskable icon’s background, so a splash screen reads as one designed surface rather than an icon pasted onto a different colour. Our companion guide goes deeper on the artwork itself: Web app manifest icons and maskable Android icons that don’t get cropped. For the files that sit alongside these — SVG, PNG, ICO and the Apple touch icon — see Favicon sizes and formats: the practical cheat sheet.

This is also the tedious part a generator exists for. EasyFaviconGenerator builds the 192x192 and 512x512 manifest icons and the site.webmanifest from one image; in its Web app manifest section, the Add a plain background and margins option puts your mark on an opaque background at a size you control, the previews show the result as an Android home-screen icon (masked, not square) and on the splash screen, and you can choose whether the icons are declared maskable, any or both.

Testing the scaled, masked result

  • Preview masked, at real size. Look at the icon as a circle and as a squircle, at home-screen size. If it only works as a full square viewed large, it does not work yet.
  • Check the manifest Chrome actually parsed. In Chrome DevTools, Application → Manifest shows the icons found on the deployed page and flags missing or unreachable files. If no manifest appears there, the <link> tag is missing or pointing at a 404.
  • Test on a real device, and reinstall after changes. Add the site to the home screen and look at the icon among real apps on your real wallpaper. Android and Chrome cache icons persistently, so after redeploying a new icon, remove the shortcut and add it again before concluding the old file is still being served.
  • Verify the deployed site, not your local files. The favicon checker fetches your live page, inspects the manifest and its icons, and previews the Android home-screen and splash results — the quickest way to catch an icon that exists on your machine but 404s in production.

Quick answers

If Chrome scales icons anyway, why declare two sizes?

Because scaling works best from a close, honest source. The 192x192 covers the standard home-screen need, the 512x512 covers larger uses and gives Chrome high-quality material to scale down from. Declaring both costs two files and removes the guesswork about which single size a given device will have to stretch or shrink.

Should I export an icon for every Android screen density?

No. That is the native-app model, with its per-density resource folders. On the web you declare the manifest sizes and the browser scales between them — which was the whole observation of the original 2016 post, and it is still how it works.

My icon is sharp but its corners are cut off. Is that a scaling problem?

No, a masking one. The mark extends beyond the maskable safe zone. Shrink it toward the centre — inside the central circle that is 80% of the canvas, and nearer 57% of the width if the mark is square — and give it a full-bleed background.

Does a 512x512 icon guarantee a crisp home-screen icon?

Only if the 512 file contains real 512-pixel detail. Generate it from a vector or a raster source at least that large, simplify artwork that will be seen small, and check the masked preview. Size is the entry requirement, not the result.

The 2016 post, in today’s terms

Strip away a decade of terminology and the original advice survives almost word for word: declare a genuinely large icon so Chrome scales down rather than up, and keep what matters in the middle because the launcher chooses the final shape. What the years since have added is precision. The manifest gives that advice a standard place to live, purpose: "maskable" turns “keep it central” into a defined safe zone with an 80% circle, and modern tooling lets you preview the cropped, scaled result before your visitors see it. Ship the 192 and the 512, design the maskable version on purpose, test it masked on a real home screen — and the icon Chrome scales down will still look like yours.

All favicon articles