> cowbell.png is 18555 bytes (256 × 256 pixels) > cowbell.svg is 4506 bytes > cowbell.ivg is 1017 bytes They did not use a gzipped version of the svg f

> cowbell.png is 18555 bytes (256 × 256 pixels) > cowbell.svg is 4506 bytes > cowbell.ivg is 1017 bytes They did not use a gzipped version of the svg file which would be a more fair comparison. Someone else in this thread actually compared with a gzipped version of the svg file and claimed the savings were still 2x. I suspect the savings from using IconVG over gzipped svg would be decreased as the size of the source file increased. Though that would need verification. If we assume the size benefits aren’t significant, I think this is really only valuable for implementing vector graphics presentation on small / embedded systems, given these leaves out a lot of svg features. It may also be the case that existing svg renderers have suffered from code bloat and aren’t very embeddable. I suspect that a well written and small svg implementation may negate many of the reasons for IconVG’s existence.