An icon that looks right in a browser can fail the moment it leaves one. Someone drops it into a slide, exports a client PDF, or drags it into a marketing email, and it either does not appear at all or it turns up sitting on a white rectangle. The icon did not change. The container did, and every file we serve is a WebP.
On 6 September 2026 we pulled 50 icons spread across our library and measured what leaving the browser actually costs: which files we hand out, where WebP stops being understood, what happens to the transparency, and what a usable PNG really weighs. Every number below comes from those 50 files.
What we hand you today
Each icon record from our API carries three image URLs, and only two of them are images. Icon Display Link resolves to cdn.thridy.com/dicons/name.webp. All 50 came back as 512 by 512 RGBA WebP, median 53.9 KB, ranging from 38.8 KB to 70.3 KB. Icon Small Link resolves to sicons/name.webp, and all 50 were 200 by 200, median 12.4 KB.
Icon Download Link still points at a .png path. We requested all 50 of them and all 50 returned HTTP 403 with a JSON body reading "Full-resolution downloads are no longer served from this address." There is no PNG waiting at that URL for your build script. The PNG comes from the download button on the icon page, and we have written about that endpoint before.
One more measurement, because it explains a result further down: re-encoding the same pixels as lossless WebP produced a median of 118 KB, more than double what we actually serve. The files on our CDN are lossy WebP.
Browsers are settled. Email is not.
For anything that renders in a browser, this is a non question. The caniuse dataset puts full WebP support at 96.09 percent of tracked global usage. Ship the WebP, move on.
Email is where it stops being simple. The Can I Email support matrix for WebP holds 59 client and version datapoints: 40 support it, 15 do not, and 4 are partial. Every tested version of classic Outlook for Windows, from 2007 through 2019, is a no. The four partials are Gmail on desktop webmail, iOS, Android and mobile webmail, and the footnote attached to them is the interesting part: Gmail converts the file to JPG.
One caveat we will not bury. Those particular WebP tests were last run on 6 February 2021, even though the dataset itself was refreshed on 10 August 2026. Treat the matrix as a direction rather than as today's truth, and if a campaign matters, send yourself a test before you send it to a list.
The transparency is the part that breaks
MDN's format reference is blunt about JPEG: it does not support an alpha channel. For a photograph that costs nothing, because a photograph is a full rectangle of pixels anyway. For a 3D icon it costs most of the file.
We decoded all 50 display files and counted the alpha channel. A median 65.2 percent of the 512 by 512 canvas is fully transparent, with a range across the sample of 46.4 percent to 81.6 percent. Only a median 15.3 percent is fully opaque. The remaining band, a median 17.9 percent, is partially transparent: antialiased edges and the drop shadow that is baked into the file.
So when a client flattens the image, about two thirds of it becomes solid matte, and the matte is usually white. On a white background nobody notices. On a tinted card, a coloured section, or a dark email, every icon in the layout grows a visible box.
What a PNG costs, and the version of that answer that is wrong
Re-encode a display file straight to full colour RGBA PNG and it lands at a median of 183.6 KB, which is 3.38 times the WebP we served, with a range of 2.67x to 4.34x. Twenty icons in a deck go from 1.05 MB as WebP to 3.6 MB as PNG. This is the point where most people conclude that PNG is expensive and start hunting for a workaround.
It is the wrong PNG. Quantize the same image to 256 colours before writing it and the median drops to 32.8 KB, which is 0.61 times the WebP we serve. It was smaller than the served WebP in 50 files out of 50, with the ratio ranging from 0.38x to 0.79x.
The quality cost is small on this kind of image. Comparing the quantized version against the original on visible pixels only, across 25 icons sampled at every third pixel, the median mean channel error was 3.2 out of 255, and a median of 3.8 percent of visible pixels moved by more than 8 out of 255. The worst icon in that set moved 10.7 percent of its visible pixels by more than 8.
The reason is the subject matter. A 3D icon in this style is a few smooth shaded surfaces on an empty canvas, not a photograph, so an indexed palette plus PNG's row filters handle it well, while our lossy WebP is paying for full colour depth it does not need. The figure usually quoted for WebP, that lossy WebP averages 25 to 35 percent smaller than JPEG at equivalent quality, is MDN's, and it is a statement about photographs against JPEG. It says nothing about an indexed PNG of an icon. Our number is the one that applies to our files.
Resize before you convert
512 pixels is a delivery size, not a placement size. Nothing in a slide, an email or a document needs a half thousand pixel icon, and the conversion is the natural moment to fix that.
Quantized to 256 colours and resized first, the median icon is 12.3 KB at 256 pixels and 4.9 KB at 128 pixels. Starting from our 200 pixel small file instead gives 7.8 KB. That same 20 icon deck, converted at 256 pixels, is 246 KB in total, less than a quarter of what the untouched WebP originals weigh.
The rule we use is twice the size the icon is placed at, capped at 512. An icon sitting in a 120 pixel box in a deck wants a 256 pixel file, not the one you downloaded.
What we would actually do
On the web, keep the WebP. If the icon renders at 200 device pixels or less, use the small file rather than the display file, which is a measurable saving we have written up separately.
In email, send a PNG at twice its placed size, quantized, with width and height attributes set on the img tag. Then do the belt and braces step: give the icon a background that matches the block it sits in, rather than relying on transparency. If a client flattens the file, there is nothing left for the flatten to reveal.
In slides, documents and PDFs, a 256 pixel quantized PNG is the right default. It imports everywhere, it keeps its transparency, and at 12 KB it does not bloat the file.
Everywhere, do not point production at the .png download link. It has been retired and it answers 403.
How we measured
We sampled 50 icons by requesting ten pages of our public icons endpoint, five icons per page, spaced evenly across all 13,335 records so the sample runs across the alphabet. The 50 span 18 of our categories, from Food and Drink to Machine and Parts. We downloaded both the 512 pixel and the 200 pixel WebP for each, recorded the byte counts the CDN reported, and decoded them locally.
All re-encoding was done with Pillow 12.3.0: PNG written with zlib optimisation on, quantisation done with the fast octree method at 256 colours, JPEG at quality 85 for the flatten test. A dedicated tool such as pngquant or oxipng would very likely beat our PNG figures, so read 32.8 KB as a ceiling and not a floor. The support figures are from the caniuse and Can I Email datasets as fetched on the day, and both are linked in the sources below so you can check the dates yourself.
Free 3D icons for this
Every icon on Thridy is free to download and use. A few that fit this piece:
- Blog Post 3D icon
- WebP File 3D icon
- Red Rocket 3D icon
- Percentage 3D icon
- Keychain 3D icon
- Chain Wallet 3D icon
Browse all 2,600+ free 3D icons or explore them by category.