The author would make an even stronger case if they showed the results after compression. On the few examples in the home page, which I compressed with gzip -9 (zstd performs similarly):

    tiger.svg.gz   29834
    tiger.tvg.gz   20533
    app-icon.svg.gz     613
    app-icon.tvg.gz     665
    comic.svg.gz   25063
    comic.tvg.gz   13262
    chart.svg.gz    8311
    chart.tvg.gz    5369

In most cases, even after gzip compression TVG still has a substantial lead over SVG.

This is evidence that the size improvement does not come entirely from the binary format (it would be possible to devise a binary format for SVG without changing the language and semantics), but from the simplified graphic primitives as well. If it was just XML overhead, compression should mitigate most of it.

zimpenfish

If you run tiger.svg through `svgcleaner`, you get a file that's 57614 (with no visual difference[1]) that compresses to 20924 with gzip or 19529 with zstd.

`svgo` gives 61698 / 21642 gz / 20228 zstd, again no visual difference.

Not really a need for TVG if you can clean your SVG as part of your deployment pipeline.

(You can go even further and trim the coordinates to 2 places of precision which ends up with 52763 / 18299 / 17114 zstd at the expense of still largely invisible differences but I've had SVGs where this level of cleaning did materially affect the output.)

[1] https://imgur.com/a/2b5CsPQ

zigzag312

I'm not sure, but it seems svgcleaner can remove unused and invisible graphical elements[1]. I don't know if TinyVG preserves them. but if it does, it's not a fair comparison.

Did you try converting svgcleaner processed SVG to a TVG?

[1] https://github.com/RazrFalcon/svgcleaner