Skip to content
user@convertitive:~$convertitive

Favicon Generator

One square image in, a complete favicon set out. Nothing leaves your browser.

A modern favicon setup in 2026 is a small bundle, not one file: a classic favicon.ico for legacy user agents and old bookmarks, PNG icons at 16 and 32 pixels for browser tabs, a 180px apple-touch-icon for iOS home screens, and 192/512px PNGs for the web app manifest. The .ico part is less painful than it sounds: since Windows Vista, ICO directory entries may contain PNG-encoded images directly, so this tool renders your image at each size on a canvas, encodes each as PNG, and wraps the 16/32/48 trio in an ICO container that costs just a 6-byte header plus 16 bytes of directory per image — all client-side, with nothing uploaded anywhere.

Drop one image here (PNG, SVG, JPEG, WebP…), or

One file, up to 16 MB. A square 512×512+ source works best. Stays in your browser — nothing is uploaded.

How to use

  1. Drop one image

    Drag any image your browser can decode — PNG, SVG, JPEG, WebP — onto the dropzone. A square source of at least 512×512 gives the sharpest results; non-square images are center-cropped automatically.

  2. Check the small-size previews

    The tool renders your icon at 16, 32, and 48 pixels on both a light and a dark checkered background — exactly the sizes browser tabs use. If the design turns to mush at 16px, simplify it before shipping.

  3. Download the set

    Grab favicon.ico (which bundles 16, 32, and 48px PNG entries in one file) plus the individual PNGs: favicon-16x16.png, favicon-32x32.png, apple-touch-icon.png at 180px, and icon-192/icon-512 for your manifest.

  4. Copy the head tags

    Copy the ready-made <link> snippet into your HTML head, drop the files in your site root, and reference icon-192.png and icon-512.png from your web app manifest's icons array.

Frequently asked questions

Is my image uploaded to a server?
No. Decoding, center-cropping, scaling, PNG encoding, and ICO container assembly all run in your browser with the Canvas API and plain JavaScript. There is no upload request at any point — Convertitive never sees your image.
Which sizes actually matter, and why these ones?
16×16 and 32×32 cover browser tabs, bookmarks bars, and history lists on standard and high-density displays. 48×48 covers Windows site shortcuts and some desktop contexts. 180×180 is what current iPhones and iPads request for home-screen icons. 192×192 and 512×512 are the two sizes the web app manifest spec and Android's install prompt expect. Everything else browsers need, they scale from one of these.
Do I still need a .ico file in 2026?
Yes, as a safety net. Browsers and crawlers that predate PNG favicon support, old bookmarks that hard-coded /favicon.ico, and a long tail of feed readers, link unfurlers, and monitoring bots still request /favicon.ico at the site root unconditionally. Serving a real file there costs nothing and avoids a steady stream of 404s in your logs.
Are transparent backgrounds preserved?
Yes. Every output is PNG-encoded — including the entries inside the .ico container — and PNG carries full alpha. The checkered previews above exist precisely so you can check how your transparent icon reads on both light and dark browser themes before committing to it.
Why is the Apple touch icon 180 pixels?
180×180 is the size iOS requests for home-screen icons on 3x Retina displays (60pt × 3). Older devices that want 152 or 167 pixels simply downscale the 180px file, so shipping the single largest size covers the whole Apple lineup. Note that iOS composites its own rounded-corner mask, so supply a full-bleed square — no pre-rounded corners needed.
What about SVG favicons?
Modern desktop browsers accept <link rel=“icon” type=“image/svg+xml”> and it is a great addition — one crisp file at every size, and it can even adapt to dark mode with embedded CSS. But Safari's support has historically lagged and many non-browser agents ignore it, so the PNG-plus-ICO set remains the safe baseline. Ship the SVG as an extra <link>, not a replacement.

About

The ICO container, and why PNG entries work

An .ico file is one of the simplest container formats still in daily use: a 6-byte ICONDIR header (reserved word, type 1 for icons, entry count), then a 16-byte ICONDIRENTRY per image recording its width and height (as single bytes, where 0 means 256), bit depth, byte length, and offset, followed by the raw image data back to back. Originally that data had to be a headerless BMP with an AND transparency mask; since Windows Vista, the data may instead be a complete PNG stream, which the OS detects by its signature bytes. That single change is what makes a client-side generator this small possible — the browser's own canvas.toBlob PNG encoder does the pixel work, and the ICO layer is just 6 + 16×n bytes of little-endian bookkeeping written with a DataView.

How browsers pick a favicon source

When several icon links are declared, browsers choose by rel type and the sizes attribute: a tab on a 2x display wants 32px, so a <link rel=“icon” sizes=“32x32”> wins over a 16px one; if nothing declared matches, most browsers fall back to requesting /favicon.ico from the site root even with no link tag present. Apple devices ignore rel=“icon” for home-screen icons entirely and look for rel=“apple-touch-icon” (falling back to /apple-touch-icon.png at the root). Installable web apps read neither — they take the 192 and 512px entries from the manifest's icons array. That split — link tags for tabs, apple-touch-icon for iOS, manifest for installs — is why a complete set has three delivery mechanisms rather than one.

Sources & references

Authoritative references behind the math, constants, and tables on this page. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.