You build a progressive web app, supply a perfectly good 512×512 icon, install it on an Android phone, and the launcher shows your logo with its corners sliced off — or floating inside an unwanted white circle, or squashed into a rounded square that crops the last letter of your name.
Nothing is broken. The system is doing exactly what it was designed to do, and the fix is a specific file you probably have not made.
The launcher owns the shape, not you
Android launchers enforce a consistent icon shape across every app on the device. Depending on the manufacturer and the launcher, that shape might be a circle, a squircle, a rounded square, a teardrop or a plain square.
The device decides. Your icon is a rectangle handed to a system that will mask it into whatever shape it uses, and you have no say and no way to detect which it will be.
Design an icon that fills its canvas — as most logos do, because that is what looks right in isolation — and the mask removes whatever falls outside. On a circular mask that is every corner: roughly 21% of the area of a square, and disproportionately the part where designers put things.
The safe zone
The specification’s answer is a safe zone: a circle centred on the icon with a diameter of 80% of the icon’s width.
Everything essential must sit inside that circle. Everything outside it is expendable — background that any mask may remove without loss.
For a 512×512 icon, the safe zone is a circle 409 pixels across, centred. Which leaves roughly 51 pixels of margin on each side that you must treat as sacrificial.
The circle is used because it is the most aggressive mask in common use. Anything that survives a circle survives a squircle, a rounded square and a plain square. Designing for the worst case is the only way to get a predictable result across devices you cannot enumerate.
Why “just add padding to my icon” is not quite the answer
It is most of the answer, with two complications.
The maskable icon is a separate file. Not your existing icon with a flag set. The manifest declares purpose per icon:
"icons": [
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
{ "src": "/icon-maskable.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
]Two files, two purposes. The any icon is used where the full canvas is shown — a browser tab, a task switcher, a bookmark list. The maskable icon is used where a mask is applied. They are genuinely different images: one fills its frame, the other is deliberately padded.
Setting "purpose": "maskable" on an icon that was not built for it is the most common mistake in this area, and it produces the worst outcome — the system now trusts that the edges are expendable, and crops accordingly.
The background must be opaque. A maskable icon with a transparent margin gives the launcher nothing to fill with. Results vary: some composite onto white, some onto black, some leave artefacts at the mask edge. Fill the whole canvas with a solid colour and the mask has something to cut cleanly.
Your logo will look smaller, and that is correct
The consequence of an 80% safe zone is that your mark occupies less of the visible icon than it would elsewhere. Next to apps whose icons fill their frames, yours can look slightly recessed.
The instinct is to scale the logo back up to compensate. Resist it — you are trading a guaranteed-correct icon on every device for a slightly larger one that gets clipped on circular launchers.
If the icon genuinely looks weak at safe-zone size, the answer is a simpler mark rather than a bigger one. Icons that work at this scale are single letters, bold glyphs, or simple silhouettes. Detailed logos and wordmarks do not survive the combination of a small render size and an aggressive mask, and no amount of padding adjustment changes that.
Checking your work
Draw the circle. Overlay a centred circle at 80% width on your icon and look at what falls outside. If any part of the mark crosses the line, it will be cropped somewhere.
Test on a real device. Install the web app on an Android handset and look at the launcher. Different manufacturers use different masks, so if you have access to more than one, use it.
Use the browser tooling. Chrome’s developer tools show the manifest and can preview icons with a mask applied, which catches the obvious failures without a device.
Check the any icon separately. It appears unmasked in other contexts, and an icon designed only for masking looks oddly small when shown in full.
What our generator does
Our favicon generator produces the maskable variant as its own file and forces a minimum of 20% padding when building it.
That behaviour is deliberate rather than convenient. The overwhelmingly common input is a logo that already fills its frame — because that is how logos are supplied — and passing it through unchanged would produce a file labelled maskable that is not. Enforcing the padding means the output is correct even when the input was not prepared for it.
It comes as part of the full icon set: the ICO, the tab PNG, the Apple touch icon, the 192 and 512 sizes, the maskable variant, site.webmanifest and the markup snippet — one image in, a ZIP out, entirely in your browser.
iOS does not do this, and that is its own problem
Everything above concerns Android. iOS takes a different approach, and the difference catches people out in the opposite direction.
iOS does not mask. It applies its own rounded-corner treatment to the Apple touch icon, but it does not crop into the artwork the way a circular launcher mask does, and it does not read the purpose field in your manifest at all. It uses apple-touch-icon and nothing else.
Two consequences.
Do not supply your maskable icon as the Apple touch icon. Its deliberate padding is not needed there, and iOS will not remove it — you get a small logo floating in a large field of background colour, surrounded by apps whose icons fill their frames.
Do not supply a transparent icon either. iOS composites transparent areas onto black, which is rarely what anyone intends. The Apple touch icon wants a solid background and artwork that fills the frame, which is the opposite of the maskable brief.
So the two platforms want genuinely different images: full-bleed for iOS, deliberately padded for Android. That is why the set has both, and why a single icon reused everywhere always looks wrong somewhere.
The monochrome icon
There is a third purpose value, monochrome, used for adaptive theming — a single-colour silhouette the system can tint to match a user’s chosen palette.
It is not widely required and its support varies, but if your mark works as a solid silhouette it costs little to supply. The rules are stricter than for the other two: it must read as a shape with no internal detail, since every pixel will be rendered in one colour, and it needs the same safe-zone padding as the maskable version because it is masked in the same contexts.
If your logo depends on colour to be recognisable, skip it. A monochrome version that reduces to an unrecognisable blob is worse than not supplying one, because the system will use it.
Generate a properly padded maskable icon along with the rest of the set using our favicon generator. Nothing is uploaded.