I'm pretty sure the same issue happens with PNGs, which being lossless are generally good for icons as they don't land up with compression artifacts like what happens in JPEGs (which the author points out are really for photographs), they also support alpha blending.
When Chrome introduced this "optimization" and it made it through to an Electron release which we were upgrading to, it really messed up the icons in a lot of places in our product such that we had to hold off the upgrade until we had SVGs to replace them.
SVGs also have the advantage of being able to respond to light/dark mode. We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.
I don't think it's possible to partially decode/render a PNG in a way similar to JPEG. The only exception I can think of is adam7 interlacing, which _does_ store the initial pass as 8x8 blocks, but I'm pretty sure PNGs with adam7 are rare in practice because they do result in larger files.
Perhaps it was a different optimisation, but it definitely made significantly downscaled PNGs look way worse under particular circumstances. It was especially noticeable on triangles we used on nodes of a tree view control.
Yeah, images with sharp contrasts like line art tend to do badly with the scaling algorithms that work well with photos. It is why browsers introduced `image-rendering: pixelated` css, but as you noted in the other comment, SVG is almost always the best answer.
its not possible to do this for pngs. Most likely though chrome is just using a quicker downscaling algorithm than your graphics editor is using (or just the wrong one. There is no universally correct algorithm, different ones work better for different image types).
Have you tried adjusting the image-rendering css property?
I can’t recall the details any more, but I recall seeing something like this in my research on the issue, it might have been a solution to the issue, or I was worried it had a noticeable performance impact.
We may also have moved to the SVGs anyway as they also look much nicer when running at different zoom levels like 125%.
> We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.
The problem is if these same element ids and styles are used in different places in your DOM, including other SVGs.
Our product is a bit of a platform with extensibility which includes icons for ui elements. It was very easy for us or our users to accidentally use the same style names or element ids when exporting from Adobe Illustrator, especially for icons which are similar to others and started as a copy.
When using SVGs as a background it’s not an issue, but we want our SVGs to be able to have different colours be usable in light or dark mode which CSS can do, except it doesn’t work when making the SVG a background.
When I referred to “styles” I was referring to classes.
If the same class was defined in a multiple SVGs under their respective <style/> elements, they would affect each other.
So sometimes if two icons were in the DOM at the same time, the one’s colours might look wrong since both had the same class names they were using.
Element ids were also not used so much for styling but instead for common SVG components (or something, I don’t know the terminology), so would similarly cause rendering issues.
Like I said it was especially common if the one started as a copy of the other in Illustrator.
The “fix” was to ensure unique element ids and class names, but this was an annoying extra step.
Using a shadow DOM for each icon which is an SVG circumvents the entire problem as they ignore anything outside their isolated DOM.
What's so funny about this is that XML is absolutely brimming with rich namespace solutions for all the problems you don't have. For example, if your users ever want to blithely roll their own "href" namespace, don't worry! The xmlns http://www.w3.org/1999/xlink is there for them to safely disambiguate all the custom:hrefs from the xlink:href things!
Meanwhile, in 2026 you've got two designers who each use their own "bgcolor" and XML is like, "Nope!"
Digression-- I just checked MDN and apparently xlink is deprecated! This makes me want to write alternate history from the mid-2000s about the href wars: XML namespacing parties where front-end designers would mash up dozens of href namespaces in the same document.
Right. It's just funny that there is an always-increasing number of extant cases like OP's for SVG and/or internal hyperlink specs where content isolation would have been much appreciated, and literally zero cases I can think of where anyone used XML namespaces to extend either SVG or hyperlinks. (As well as the case I mentioned above where the working group apparently just said "fuck it" wrt specifying xlink at all.)
Even toy examples! I'm trying to think back through my recollection of the W3C archives, and I can't remember a single time when a proposed feature had a demo that utilized XML namespaces. Unnamespaced pseudocode, yes. JS polyfills, yes. XML namespaces? Please link me some examples for my fan fiction research.
Ah this is weird! My understanding is that png doesn't store the images like jpg at all, they use a palette of all the colors in the image. Then each pixel is a reference to this palette. So it's not IDCT scaling, but I imagine there are other tricks to save on space/cpu when decoding pngs.
Guess: same icon used in very small size for lists/menus and much larger when you select the item. Also, if the same one is used for all resolutions, the actual size can vary widely between monitor sizes, DPIs, resolutions, scales. Good to have one that looks decent to people who see it large and/or care about quality
When Chrome introduced this "optimization" and it made it through to an Electron release which we were upgrading to, it really messed up the icons in a lot of places in our product such that we had to hold off the upgrade until we had SVGs to replace them.
SVGs also have the advantage of being able to respond to light/dark mode. We just needed to put each icon in its own shadow DOM to avoid styles clashing between the different SVGs if they happen to be named the same which was a bit of an annoyance for our graphic designer.