PNG favicon set without opening a desktop icon packer

You have one clean PNG of the mark. Marketing wants it in the tab. The PWA manifest wants 192 and 512. Apple wants apple-touch-icon. Someone pastes a Notion embed and suddenly you need 32×32 that still looks like the brand at a glance.

I used to open a desktop icon packer (or worse — ask design for "the full favicon set") every time a side project needed a tab icon. That path is fine for a brand refresh. It's painful for a Friday afternoon deploy where the logo already exists as a single PNG.

What "a favicon set" actually means now

It's rarely one favicon.ico anymore. A boring but complete set usually includes:

• 16 / 32 — browser tab + bookmarks (often still ICO or PNG)
• 180 — apple-touch-icon (iOS home screen / Safari)
• 192 / 512 — PWA icons in the web manifest
• Optional 48 / 96 — Android chrome / shortcut leftovers some templates still expect

You don't need twelve sizes. You need the sizes your HTML + manifest actually reference — and they should all come from the same source PNG so color and crop stay consistent.

What goes wrong with the usual shortcuts

Ship one 512 PNG and call it a day — tabs look soft, Apple crops weird, and the manifest auditor complains.

Ask design for every size — correct for a rebrand; overkill when you already have the master PNG and just need derivatives.

Desktop packers / Photoshop actions — work until you're on a locked laptop, a Chromebook, or someone else's machine without the action installed.

Upload-to-convert sites — easy to regret when the mark is brand IP. I don't want the logo sitting in a stranger's temp bucket because I needed a 180px touch icon before standup.

Screenshot / crop by eye — wrong DPI, wrong padding, off-center mark. You'll notice it every time you open the tab.

What I actually need from the resize step

For frontend / DX use, the checklist is boring:

1. Square source (or a clear crop to square) — no stretched logo in the tab
2. Explicit pixel sizes — 16 / 32 / 180 / 192 / 512, not "whatever looked fine"
3. Transparent background preserved when the PNG has alpha
4. No upload — file stays in the tab (Offline litmus still applies)
5. Predictable names — favicon-32.png, apple-touch-icon.png, not download (9).png

If the tool can't do those five, I'm back to ImageMagick / sharp in a one-off script.

A tab that fits the handoff

When the master mark is already a PNG and I just need the favicon / PWA sizes before a deploy, I've used Uwarp's PNG → favicon tool — drop the file, grab the set in the browser. Worth trying when the alternative is another desktop install or an upload converter you can't audit.

For a recurring pipeline (every brand refresh, every white-label tenant), script it: sharp, ImageMagick convert, or a tiny Node job in CI that emits the sizes your site.webmanifest lists. The tab is for the one-offs that shouldn't block a PR.

Wire the sizes you actually ship

A few rules that stopped me from collecting orphan icons in /public:

• Commit the master PNG (or SVG + export) in the brand / design-system repo; generate favicon sizes at publish time
• Only reference sizes you generate — don't leave dead <link rel="icon"> tags for 96px you never build
• Name by intent + size (apple-touch-icon-180.png), never logo_final_v3.png
• Document the set in the README so the next person doesn't invent a new size in Slack

Favicon generation is packaging, not design. Treat it like that and the folder stays boring.

Tiny habit

Next time a repo needs tab + PWA icons and you already have one clean PNG, don't reopen the icon packer and don't upload the brand mark. Resize in a local-ish tab (or a one-liner CLI), drop the files next to site.webmanifest, verify the tab looks sharp at 1x and 2x, ship.

Fewer blocked deploys. Fewer mystery PNGs in Downloads. Same source mark — just the sizes the browser and the home screen actually ask for.