PNG to ICO Converter

The dev shop ticket is a single sentence: 'Icon needs to be .ico with the usual sizes.' The usual sizes. You have a beautiful 1024-pixel PNG of the logo, and somewhere between that file and 'the usual sizes' lies a container format from the 1990s that bundles multiple images into one — a format your image editor may not even export without a plugin, and that half the online converters handle by wrapping your single PNG unchanged, producing an .ico that renders blocky at 16 pixels because it contains nothing but a big image.

The failure is invisible until it isn't. The favicon looks fine on your retina laptop, where the 256-pixel entry downsamples smoothly. Then someone opens the site on Windows, and the taskbar icon is a smear; the browser tab shows a gray blob. The file was valid .ico. It was just empty — one size pretending to be four.

This converter does the real job: true multi-size packing, in the browser. Give it a PNG, choose your entries — the classic 16/32/48 favicon trio, the full 16/32/48/256 application set, or any combination — and it resizes the source properly for each, encodes them, and writes a well-formed icon directory around them. Individual per-size PNGs come alongside, because the modern web wants those too.

1. 1

   Load your source PNG

   Square is strongly preferred — the icon world is square by convention. Transparent background is the professional default; a logo with baked-in white corners will carry those corners into every icon size.

2. 2

   Check the source resolution

   The tool reports your PNG's dimensions. At least 256 pixels on a side means every standard icon size can be generated by clean downsampling. Smaller sources upscale for the bigger entries — legal, but soft.

3. 3

   Choose your size set

   The favicon preset packs 16, 32, and 48. The application preset adds 256. Custom selection is there for the odd cases — a 24-pixel entry for legacy toolbars, a 64 for high-density taskbars.

4. 4

   Review the per-size previews

   Each entry renders at its true size, side by side. This is where a 16-pixel icon either survives or dies — check that the mark still reads before shipping it.

5. 5

   Convert and download

   The .ico assembles locally: resized entries, encoded, indexed in a proper icon directory. The per-size PNGs are available in the same download, for the link-tag setup modern sites use alongside the .ico.

6. 6

   Deploy

   Drop favicon.ico at your site root, or wire the link tags from the Favicon Generator's snippet. For app projects, the .ico lands in your build's resource pipeline as-is.

An .ico file is a table of contents plus a stack of images, and the layout is small enough to hold in your head. It starts with a six-byte header: two bytes reserved, two bytes declaring the file type as icon, and two bytes counting the images. Then comes one sixteen-byte directory entry per image — width, height, color count, reserved byte, color planes, bit depth, the image's byte size, and its offset from the start of the file. The image data itself follows, in order.

Two details in that directory encode the format's history. First, width and height are single bytes — 0 to 255 direct — with zero standing in for 256, the format's ceiling. That is why no .ico anywhere holds a 512-pixel image: the field cannot express it. Second, the entries store each image's byte size and file offset, which is how a renderer can jump straight to the 16-pixel entry without reading anything else — a genuinely elegant design for 1990s memory constraints.

The image payloads themselves come in two flavors. The classic flavor is a Windows BMP structure — a 40-byte bitmap header, pixel rows, and an AND mask, a 1-bit-per-pixel transparency layer that predates alpha channels by a decade. The modern flavor, supported since Windows Vista, embeds a complete PNG file as the entry's payload. A 256-pixel PNG entry is typically five to six times smaller than the equivalent BMP data, and every current Windows and browser renderer reads it. This converter writes PNG entries — the byte savings are the whole argument — while emitting BMP-style entries only where a specific legacy target demands it.

Transparency travels through the alpha channel of 32-bit entries, identical in meaning to PNG's alpha. The ancient AND-mask mechanism is still written by some tools for compatibility; modern renderers ignore it when 32-bit data is present, so a well-formed converter sets it to all-visible and lets alpha do the work. The practical upshot for you: transparent regions of your PNG come through transparent at every icon size, no mask debugging required.

Header:   00 00 01 00 04 00            reserved 0 · type 1 (icon) · 4 entries
Entry 1:  10 10 00 00 01 00 20 00 A8 04 00 00 46 00 00 00
          16×16 · 1 plane · 32 bpp · 1,192-byte payload · data starts at byte 70
Entry 2:  20 20 00 00 01 00 20 00 60 09 00 00 EE 04 00 00
          32×32 · 2,400-byte payload · data starts at byte 1,262 (70 + 1,192)
Entries 3 and 4 follow the same 16-byte shape, offsets accumulating through the file

Reading it byte by byte: the directory values are little-endian, so a 1,192-byte size appears as A8 04 rather than 04 A8, and the 32-pixel width is a single 20 byte — 0x20 in hexadecimal. Entry 1's payload offset of 70 is the header (6 bytes) plus four directory entries (64 bytes), and every later offset is the previous one plus the previous payload size. Sixteen bytes of accounting per image is the entire index — small enough to verify by hand, which is exactly what a suspicious engineer should do.

Run the arithmetic on the standard application set — a 1024×1024 source PNG packed into 16, 32, 48, and 256 entries — and the format's economics become visible:

The 70 bytes of overhead deserve their moment: six bytes of header plus three or four sixteen-byte directory entries. That is the entire cost of multi-size packaging — the reason bundling sizes is not a optimization decision but a formatting one. The images dominate; the container is noise.

The complete scenario, production-shaped: a product with a marketing site and a Windows desktop app, one 1024×1024 transparent master PNG, and every icon destination fed from it. Four artifacts, four destinations:

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" type="image/png" href="/icon-192.png" sizes="192x192">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

Two caching realities govern deployment day. Favicons are cached harder than any other site asset — browsers frequently keep serving an old one after every other resource has updated, and the reliable test is fetching the file's URL directly with a version query appended. Windows Explorer maintains its own icon cache for applications, so a rebuilt executable can display yesterday's icon for days afterward: the conversion worked, and the display layer simply has not caught up. Both phenomena generate 'the converter didn't work' reports that are actually cache reports.

That coverage-per-kilobyte — every requester from a 2026 Chromium tab to a Windows 7 taskbar to an iOS home screen, inside 60 KB — is why the icon pipeline deserves its own checklist instead of being improvised per project. The master PNG stays in version control; the four artifacts regenerate from it in under a minute whenever the mark changes.

Install a web app on Android and the launcher does something no favicon pipeline prepares you for: it crops your icon to a shape — a circle on stock Pixels, a rounded square or squircle on other OEMs — and if your manifest only ships a regular icon, Android pastes it onto a white disc first, so the logo floats in a white circle smaller than every native app beside it. The fix is a maskable icon: a manifest entry declared with purpose "maskable", designed so its content survives any mask the launcher applies.

The geometry is a published safe zone: a centered circle with a diameter of 80% of the icon's width — a radius of 0.4 times the icon size. Anything inside that circle survives every known launcher mask; anything outside is at the mercy of the shape. The standard design recipe follows from it: a solid background color or gradient bleeding to all four corners, and the mark itself drawn to occupy roughly the central 70–75% of the canvas, comfortably inside the zone with enough weight to read at launcher sizes.

The one trade-off worth weighing before shipping a single 'any maskable' file: browser tabs and bookmark lists display the same padded icon at 16 to 32 pixels, where generous padding reads as a shrink-wrapped logo. Large-traffic sites usually ship both variants — the unpadded mark for 'any' destinations and the padded one for 'maskable' — at 192 and 512 pixels each, four small PNGs that cost less than 20 KB combined and settle every launcher on the device.

The format's constraints are few but firm, and every one of them eventually surfaces in a support thread:

• The 256 ceiling. Width and height live in single bytes; 256 is encoded as zero. Nothing larger fits, period — larger marks belong to PNG files in web app manifests, declared separately.
• Tiny-size legibility. A logo that reads at 1024 can dissolve at 16. Inspect the small entries at 100 percent before shipping; a simplified variant for the smallest sizes is the professional fix when detail vanishes.
• Upscaled sources. A 128-pixel source generating a 256 entry is interpolated — legal, soft, and noticeable. Start from at least 256 pixels, ideally 512 or 1024.
• Non-square inputs. The format technically allows rectangular icons; the ecosystem practically does not. Pad to square with transparency and every renderer stays happy.
• Legacy compatibility. PNG entries require Windows Vista or later — which is to say, everything still running. Only genuinely ancient software needs BMP entries, and the converter can emit them when you meet it.
• Entry order. Renderers generally pick the best match regardless of order, but writing entries small-to-large is the convention tools and checkers expect. The converter follows it; so should any custom packing you do later.

The smallest entry is where icon design succeeds or fails, and the failures follow predictable arithmetic rather than taste:

• Sub-pixel strokes. A stroke four pixels wide on a 1024-pixel master covers 0.4% of the canvas; scaled to 16 pixels it becomes 0.06 pixels — not thin, but mathematically absent. To survive at 16, an element must hold at least one full pixel: roughly 6% of the canvas width, which is 64 pixels on the master. Most logos' fine detailing fails that test by an order of magnitude.
• Wordmarks. Five letters across 16 pixels allocates about three pixels per letter, which is not reading — it is texture. The professional move is a dedicated small mark: the initial, the container shape, or the simplified glyph.
• Dark-taskbar contrast. Windows 11 defaults to dark mode, and an icon tuned against white can float there as a pale smudge. Preview every size on both a light and a dark background before shipping; at true-size previews, it is a ten-second check.
• Trusting the automatic downscale. Resampling produces a technically valid 16-pixel entry that is optically mush. Applications with real design budgets ship hand-tuned small variants; everyone else should at least run the squint test on the preview — if nothing reads at arm's length, simplify the source and reconvert.

More people than the format's age suggests, because two ecosystems still require it:

• Web developers — the /favicon.ico root file that browsers request by default, alongside modern PNG and SVG declarations
• Windows application developers — .exe and shortcut icons remain .ico territory, with 256-pixel entries for high-DPI desktops
• Electron and Tauri app teams — packaging cross-platform builds whose Windows target needs a proper multi-size icon
• Brand and identity designers — delivering the icon bundle as part of a complete brand asset kit
• IT admins — favicon and shortcut icons for internal tools rolled out across fleets of Windows machines
• Game developers — Windows builds of indie titles, where the shortcut icon is often the last asset finished

The web side of that list is largely belt-and-suspenders now — link-tagged PNG and SVG favicons cover the modern browsers — but the application side is current, not legacy. Windows remains an .ico world whenever an executable needs an icon, and the 16-through-256 bundle is still what the platform's shell wants. The Favicon Generator covers the web-specific half of the job, head tags included; this converter is the container specialist.

Three ways to declare an icon, each with a real constituency:

The strategy that mature sites converge on is the trio: an SVG favicon for the browsers that render it, a set of PNGs at 32 and 180 — the latter doubling as the apple-touch-icon — declared in the head, and the multi-size favicon.ico at the root for the long tail of default-URL fetchers. Generating all three from one source is exactly the Logo Resizer into this converter, with the Favicon Generator writing the tags. One upload, three formats, every requester satisfied.

The one holdout worth a sentence: Safari does not support SVG favicons, which is the single fact keeping PNG and ICO files in every serious setup. When that changes — and eventually it will — the ICO's role narrows to Windows application icons. Until then, the format born in the Windows 3.0 era remains part of the standard kit, and knowing what is actually inside one puts you ahead of most of the tooling that generates them carelessly.

The entire packing operation — resizing each entry, encoding PNG payloads, writing the icon directory, assembling the file — is browser-local work. Your PNG is read by the File API, drawn to canvases at each target size, encoded, and the resulting bytes are concatenated into the .ico structure in memory. The download appears; the tab closes; nothing persists.

For app icons in active development this is more than a comfort feature. Icons ship in unreleased software, carry brand marks under embargo, and pass through plenty of pre-launch hands. A converter with a server-side stage — and most of them have one — becomes another entry in the vendor audit. This one never appears on that list, because there is nothing to audit: no upload, no storage, no processing on anyone's hardware but yours.

Three tools complete the icon pipeline:

• Favicon Generator — the full favicon kit with the HTML head snippet to declare it
• Logo Resizer — the square, transparent, right-sized master that conversions should start from
• PNG to JPG Converter — the format workhorse for every non-icon destination in the asset kit

The production sequence, one more time: master logo at 1024, resized and padded to square, packed here into a multi-size .ico, declared in the head, served at the root. Six steps, four of them automated, and the icon works everywhere from a 2026 browser to a Windows 7 taskbar — which, somewhere, somebody is still running.