[aleyan]

I have been using SVGs for charts on my blog for a couple of months[0] now. Using SVGs satisfied me, but in all honesty, I don't think anyone else cares. For completeness the benefits are below:

* The charts are never blurry

* The text in the chart is selectable and searchable

* The file size could be small compared to PNGs

* The charts can use a font set by a stylesheet

* The charts can have a builtin dark mode (not demonstrated on my blog)

Additionally as the OP shown, the text in SVG is indexed by google, but comes up in the image sections [1].

The downside was hours of fiddling with system fonts and webfonts and font settings in matplotlib. Also the sizing of the text in the chart and how it is displayed in your page is tightly coupled and requires some forethought.

[0] https://aleyan.com/blog/2025-llm-assistant-census

[1] https://www.google.com/search?q=%22slabiciunea+lui+Nicu+fore...

[cainxinth]

That's the kind of thing you do not for the users but because of your own standards, and even if no one else appreciates it, you always do.

[masswerk]

That's totally correct! I once replaced some blurry scans from the 6502 manual by SVG versions, and, while I was at it, I coded them by hand (really, because for this particular job it seemed easier than doing it in a drawing program.) While nobody will notice, it's satisfactory.

[1] https://www.masswerk.at/6502/6502_instruction_set.html#stack

[ale42]

Nobody will notice, because that's how it should be... personally I often notice when it's bad: blurry plots, JPEG noise that should not be there, and so on, and think "oh no, another one who has no idea about how to do images properly..."

[oneeyedpigeon]

90% of your users will benefit from it without even realising. 9.9% will silently appreciate it. If you're lucky, the remaining 0.1% will tell you they appreciate it!

[the_other]

Users definitely benefit from:

- smaller file sizes

- dark mode

- readable text

- selectable text

[mk12]

Another thing to watch out for with SVGs is how they appear in RSS readers or browser reader views. If you're using external SVG files then it should be fine. If you've optimized them by embedding into the HTML, then you need to be careful. If they rely on CSS rules in the page's CSS then it's not going to work well. For my website I try to make the SVGs self-sufficient by setting the viewBox, width, and height attributes, using a web safe font, and only relying on internal styles. You can still get some measure of light/dark mode support by setting fill or stroke to currentColor.

[chrismorgan]

My advice, for web pages: always specify the <svg> width and height attributes, or the width and height properties in a style attribute, because if non-inline CSS doesn’t load (more common, for various reasons, than most people realise), the SVG will fill the available width. And you probably don’t want your 24×24 icon rendered at 1900×1900.

(For web apps, I feel I can soften a bit, as you’re more likely to be able to rely on styles. But I would still suggest having appropriate width/height attributes, even if you promptly override them by CSS.)

[anon1395]

This, so much this. It is extremely annoying when I have a slow connection and I have to scroll down ages to get to the page content.

[coder543]

They appear to have “solved” the RSS problem by only providing one sentence of content with each entry in the RSS feed.

[Theodores]

To complete the test, the website needs an HTML page that is mostly SVG. I think that might stand a chance of getting into the main search results rather than just the image search.

Also of interest for me would be whether SVG description markup gets picked up in the index.

To complete the search of possibilities, having the SVG generated by Javascript on page load would be of interest, for example, with some JSON object of data that then gets parsed to plot some SVG images.

Your SVG graphs are very neat and nobody caring is a feature not a bug. If they were blurry PNGs then people might notice but nobody notices 'perfection', just defects.

I noticed you were using 'NASA numbers' in your SVGs. Six decimal places for each point on a path is a level of precision that you can cut down with SVGOMG or using the export features from Inkscape. I like to go for integers when possible in SVG.

The thing with SVG is that the levels of optimisation go on forever. For example, I would set the viewbox coordinates so that (0, 0) is where the graph starts. Nobody would ever notice or care about that, but it would be something I would have to do.

[aleyan]

Oh man, this is a deep mine to dig. I haven't even thought about svg size optimization. The default blog template I used really wants me to use hero images, and the jpgs are already hefty. I just looked at my network panel, and it seems the font files are loaded once per svg on initial load and then are cached.

What is the motivation for viewbox coordinates being at (0,0)? I have been thinking about setting chart gutters so that the graph is left aligned with the text, but this seems like an orthogonal issue.

[Theodores]

Okay, you did ask...

Rather than use MatLab to create your bar charts, you could do something like this.

Here I am assuming you don't want standalone images that others can steal but you do want maximal SVG coolness.

Move the origin with viewBox voodoo witchcraft to 0,0.

Add a stylesheet in your HTML just for your SVG wizardry.

Create some CSS properties scoped to SVG for your colours, for example svg { --claude-code: red; --cursor: orange; --github-copilot: yellow; } and so on.

Put them in the stylesheet, and add some styles, for example claude-code line { stroke: var(--claude-code); } and so on.

Rather than use paths in groups with clip paths and whatnot, just use a series of lines, made nice and fat. Lines have two points, and, since the viewBox is zeroed out to the origin, you only need to specify the y2 value, with y1, x1 and x2 taking the defaults of zero. The y2 value could be whatever suits, the actual value divided by 1000, 10000 or something.

Put each line in a group with the group having a class, for example claude-code.

Add the label to the group with its own transform to rotate the text 45 degrees.

Add a transform to the group to move the fat line and its label along the y axis using a translate.

Rinse and repeat for all entries on the graph.

Now do some labels for the other axis.

As for the title of the graph, move that out of the SVG file. Put the SVG file in a figure element and put the title in a figcaption element. Add CSS for the figcaptions.

With SVG in HTML there is no need to do xlink and version things, just keep it simple, with just the viewBox and no width/height. Scale your figures in CSS with the SVG set to fill the space of the figure, so we are going full width.

You can also use some title elements for mouseovers, so, hover over a bar and you get the actual data number.

Why do it this way?

Say you don't like the colours or you want to implement dark mode. You can do the usual prefers media query stuff and set your colours accordingly, for all the graphs, so they are all consistent.

Same goes with the fonts, you want all that in the stylesheet rather than baked into every SVG, so you can update them all with one master change.

As for the last graph with lots of squares, those squares are 'rect' not path, for maximum readability. The rectangles can be put in a defs container as symbols, so you have veryLightBlueSquare, lightBlueSquare, BlueSquare and so on. Then, with your text you can put each value in a group that contains a text node and a use tag to pull through the relevant colour square.

[AndrewSwift]

Yes! We do that with svija.com/en — an all SVG website with an HYML wrapper so it displays at the correct size.

[NicuCalcea]

> Also the sizing of the text in the chart and how it is displayed in your page is tightly coupled and requires some forethought.

I used to make a lot of charts with R/ggplot and the big disadvantage is, as you mentioned, the sizing of elements, especially text. So I wrote a small function that would output the chart in different sizes and a tiny bit of JS to switch between them at different breakpoints. It worked pretty well I think, the text was legible on all devices, though I still had to check that it looks fine and elements aren't suddenly overlapping or anything.

Another advantage of SVGs is that they can have some interactivity. You can add tooltips, hovers, animation and more. I used ggiraph for that: https://ardata.fr/ggiraph-book/intro.html

[Ciantic]

It does come up in normal results for me, I don't need to go to the images section, the page has keyword for testing lmtbk4mh, see result https://www.google.com/search?q=lmtbk4mh

[alberth]

Chartist is an amazing JS include that is tiny (10kb), that makes it super simple to create beautiful SVG charts.

It’s way undervalued and rarely gets updates.

https://gionkunz.github.io/chartist-js/

[bArray]

What are you using to produce the graphs?

I wrote a small graphing library for mine [1], but it has limitations.

[1] https://coffeespace.org.uk/projects/sound-source-delta.html