Every Brand Icon File app.onepassapps.com Ships: 7 Files, 84,010 Bytes, Measured

I work on OnePassApps, the team behind app.onepassapps.com. This post is a byte-level read of the brand image files our own site serves - the favicons, the touch icon, the install icons and the social card - because none of them had been measured before, and the numbers turned out to be more interesting than I expected.

Everything below was fetched over plain HTTPS from outside the browser and read byte by byte: PNG chunks decoded by hand, the ICO container directory parsed, and a SHA-256 taken of every file. The raw measurements are in content/brand-icon-assets-2026-11-04.json.

Seven files, 84,010 bytes, no duplicates

Seven files, seven different SHA-256 digests, 84,010 bytes in total. Nothing in that list is a re-serve of anything else - including the two 512x512 PNGs, which are different files with different bytes.

The HTML head declares four of them: /favicon.ico and /favicon.svg as icon links, /apple-touch-icon.png as the touch icon, and /og-image.png for both og:image and twitter:image. The web app manifest names the other three: /icon-192.png, /icon-512.png and /icon-maskable-512.png, the last one with purpose: "maskable".

The .ico holds three PNGs, not three bitmaps

favicon.ico is 3,556 bytes and its directory table lists three entries: 16, 32 and 48 px. Every one of those entries is a PNG image inside the container, not a BMP or DIB. The 16 px frame is 570 bytes, the 32 px frame 1,167 bytes and the 48 px frame 1,765 bytes.

That matters more than it sounds. A 32-bit BMP frame at 48 px is several kilobytes of uncompressed pixel data before the entry header, and a browser still has to decode it. The PNG frames compress the flat-colour artwork to a fraction of that, which is why the whole three-size file fits in 3,556 bytes. The 16 px frame keeps transparent corners: 212 of its 256 pixels are opaque and the top-left pixel has alpha 0.

The SVG is 531 bytes and two colours

favicon.svg is 531 bytes: a viewBox="0 0 32 32" canvas with six shapes and exactly two fills, #00E5D0 and #0B0D0F. There is no gradient, no filter and no embedded raster - a circle, a stem, a dot, a rounded rectangle and two eye circles. Two colours, six paths, half a kilobyte, and it stays crisp on any display.

Two icons are transparent and one deliberately is not

This is the part worth copying.

• /icon-192.png and /icon-512.png have transparent corners. The top-left pixel of the 512 px file has alpha 0, and the artwork starts 8 px in from each edge, so the drawn mark occupies 496 px of the 512 px canvas. The 192 px file is the same drawing scaled: its mark runs from 3 to 188, which is 186 of 192 px. Both are about 97% of the canvas.
• /icon-maskable-512.png has no transparency at all: 262,144 of 262,144 pixels are opaque, and the corner pixel is #00E5D0.

The maskable variant is the same drawing in the same position - its dark artwork bounding box is 72,64 to 439,415, identical to the 512 px file's - on a solid teal field that bleeds to the edge. That is exactly what a maskable icon is for: the platform may crop it into any shape it likes, so the background has to reach every corner while the recognisable mark stays inside the safe zone.

It is also why the maskable file is smaller than the plain one - 8,750 bytes against 18,385 - even though it has no transparent pixels at all. A flat teal field compresses better than the same artwork over an alpha channel.

The touch icon is deliberately opaque

/apple-touch-icon.png is 180x180 and every one of its 32,400 pixels is opaque, with a #00E5D0 corner. iOS composites a transparent icon onto black, so a transparent home-screen icon comes out with a dark square behind it. Ours is the teal field all the way to the edge.

That is the opposite of the browser tab icons, where transparency is what lets the artwork sit on whatever the browser or the OS theme paints behind it.

The social card is 42,818 bytes of near-black

/og-image.png is 1200x630 - the standard link-preview ratio - and it is the largest of the seven by a wide margin: more than twice the 512 px icon and about twelve times the favicon.ico. Its corner pixel is #0B0D0F, the near-black the site uses as its background, with the teal mark and light text on top. All 756,000 pixels are opaque.

One thing that does not exist

/icon.svg returns HTTP 404 with a 14,320-byte HTML error page. The SVG lives at /favicon.svg; /icon.svg was never a URL here. It is exactly the kind of plausible guess that ends up written into a manifest somewhere and then breaks an install prompt.

All seven revalidate after four hours

Every one of the seven files is served with the same header:

Cache-Control: public, max-age=14400, must-revalidate

Four hours of freshness, then a conditional request. Each file also carries its own ETag, so a revalidation is a 304 rather than a re-download. The 42 KB social card is treated the same way as the 531-byte SVG - the right call, since the card changes whenever the site does and the favicons essentially never do.

What to copy from this

If you are setting a site up and want the boring part to be right:

1. Ship an ICO whose frames are PNGs, not BMPs.
2. Give the maskable icon a full-bleed background and keep the mark inside the safe zone.
3. Make the touch icon opaque, and leave the browser tab icons transparent.
4. Point the SVG at /favicon.svg and do not invent /icon.svg.
5. Put a real Cache-Control on the brand assets instead of letting the host decide.

Our own Icon Studio builds favicon packs and app-icon sets in the browser tab, and the guides explain how the browser-local tools work.

I work on OnePassApps, the team behind app.onepassapps.com - the studios process the file in the tab, not on a server.