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.
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.
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..."
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!
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.
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.)
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
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.
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.
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.
Though it'd discourage anyone to run off with this idea.. b/c SVGs are unfortunately kinda janky
My top 3 issues are:
- not even overly complicated SVGs, especially with text, will render notably different in different browsers (and renderers like Batik/Inkscape/SalamanderSVG/etc). I have no idea why.. PDFs don't have this issue. While I haven't tried, but I don't think PDFs are as easy to generate programmatically as SVGs
- SVGs have completely broken linking. You can embed an <svg> inside another <svg> to reuse an element - but for some reason it's limited to a link depth of 1! So you can't link an <svg> that links an <svg>. So SVG aren't safely composable - which drives me nuts.. (ex: making a large display panel in SVG that has subcharts)
- Maybe minor.. but tooltips in SVG (which are super handy.. for instance in plots to display additional info about a data point) don't work when the SVG is in an HTML page. They seem to only work when you open SVG in a separate tab.
More abstractly they just have very weird perf issues. Some mildly complex SVGs take GBs of RAM and 1> min to render. But it's unclear which parts are performance sinks.
A few years back I updated my site[1] so all of the UI graphics (e.g., logos, icons in the menus) are SVG sprites baked into the HTML. It resulted in a lot fewer requests per page, lower overall page size, and sharp navigation on any device at any resolution. It works great, though it was a lot of initial work to get it working.
Thanks for the kind words! It is not at all profitable, but it gives me purpose, and scratches a particular intellectual itch. I wish I could afford to make it my full-time job and just write every day without worrying about day-job income, but alas, the universe currently desires otherwise.
Text selection is a little unintuitive (iOS on iPhone) If I’m not directly over the text I get a little magnified bubble instead. On plain HTML text selection is a little more forgiving if your long presses are not accurate.
Yeah this is a big part of the reason SVGs are dangerous if treated like normal image files. They are basically equivalent to HTML w/ embedded CSS and can even execute javascript.
If you aren't careful they can be used for XSS and all kinds of nasty stuff.
They are also super useful in general though despite that.
There were some tools that let you do a lot of flash-type things using html5 and svg. I used Tumult Hype for an animation project a few years ago, but I don't think it ever became as popular as Flash.
Svgs are capable of anything. You can draw anything with it as it’s just a format for vector graphics. The vectors can be manipulated so you can even make a 3D game engine from it if you wanted.
The only thing that separates it from html and css is that html and css biases towards website styled stuff. HTML is designed for text boxes and that kind of stuff while svgs bias more towards a neutral drawing medium: shapes and vectors.
So because it’s more neutral you can even make a html engine from svg if you so wanted.
Just serving a whole SVG file directly never even crossed my mind as an option, very cool.
A while back I used a giant interactive SVG as the UI for a site I was prototyping, albeit wrapped in a normal HTML page. It was easy to set up and worked reasonably well, but I found that in Firefox performance started to degrade beyond a few thousand elements and so converted everything (except some accessibility features) to use a canvas instead. (The core of the old version is still deployed here if you want to see how far you can push it: https://freeclimbs.org/wall/demo/edit-set )
One thing I love about SVGs for websites is their stability across many contexts, browsers, etc. Everything is pinpoint, coordinate based, nothing moves around unexpectedly. You define it once, it's done.
I realize it's far from a best practice and even explicitly stated as a bad idea somewhere in the SVG spec, but the idea of a document editor where you can individually position each and every character and make detailed, individual glyphs natively without loading fonts is interesting to me.
Are there any examples of this? Or perhaps different (better) approaches to a document editor with the advantages I said above?
I do not observe any performance problem in Firefox (Nightly, Linux/Sway), and I’d say text selection is very good, with these caveats:
• Caret mode (F7) doesn’t work at all.
• Triple click selects all the text on the page, rather than just that of a single <text> element as I’d have expected (in which model you’d use <text> for a paragraph and <tspan> for its lines, and thus get the normal triple-click behaviour).
• Click and drag on a text link starts selection or drags the already-selected text, rather than dragging the link so you can drop it in a new tab or such. And if you mouse up on the same link (regardless of having left it), it activates.
• If you start a selection, it is only updated while you’re moving over text. Drag past the end of the line, then down, and it should select more text, but it only actually will when you move back over text.
• If text is selected, clicking outside text doesn’t clear the selection. (Probably the same root cause.)
• Shift+Up and Shift+Down select to the start or end of the containing <text> element, rather than operating linewise. (Because there’s no such thing logically, it’d require heuristic work. Or for people to implement flowed text, like Inkscape did but sadly then it was pulled out of the spec for some reason.)
There are also a couple of issues specific to this document:
• Document order is not sensible. For example, it goes title, then side nav title, then footer, then body text, then “Home”, then side nav contents, then magic keyword. But this does show a broader problem: in HTML it’s not the easiest to get stupid document ordering (possible, but you have to go a little out of your way), but in SVG it will happen unless you’re careful.
• Also likely to happen unless you’re careful: multiline text sometimes lacks the trailing spaces necessary to separate words once the line break is ignored (since there’s no such thing as a line break in SVG 1.1, only a shifted cursor position). For example, “Inkscapefor” fails, whereas “willing to” succeeds.
—⁂—
Chromium is interesting. Supports caret browsing (+), Up/Down do something weird (−), triple click only selects that <text> element (+), you can’t start a text selection in a link (±), but you can’t drag the link either (=), and while selecting, any time the pointer is not over text, it’ll shift that selection boundary to something like the start of the document (−), except it’s not actually the start because it excludes the title text for some reason.
I think that's just the standard behavior of the selection algorithm with that particular layout. FF might be applying some kind of debouncing or hysteresis to keep it from flickering, but if so it's making all selection sluggish.
SVGs are under explored in generative AI. They are effectively a graphics language of their own. LLMs can write them directly without a vision architecture, and understand them in ways that non-vector graphics cannot.
Selectable and more importantly searchable text is one of the reasons why I occasionally open Large SVG diagrams in browser instead of the usual image viewer.
I’ve done some cool things with the built-in SMIL animation too. You can control it with JavaScript and CSS… Watch out for the filters though — they can be pretty heavy compute-wise.
Viewed it on iPhone in the passenger seat of my son’s 79 Thunderbird. Doesn’t reflow and is a disaster in portrait but I pinch zoomed it in landscape and it was readable.
The search term lmtbk4mh is found with Brave Search (3 hits so far, but it cannot provide a description of the SVG site). DuckDuckGo Search has zero results at this moment.
The page is old enough that it wouldn’t surprise me if Google and Bing used to index it and are capable of indexing it, but no longer do. A lot of older stuff where you know exactly what’s there just can’t be found any more.
Flash did not disappear because of an unfortunate accident. It disappeared because Adobe was unwilling to fix its outdated system and rampant security flaws.
I did wonder why they didn't just switch out actionscript for js and use plain html/svg/canvas. I'm kind of glad they didn't but I think there would have been money in doing so.
Actually they did, Adobe still makes the Flash authoring tool but they call it Animate, it exports files that work with an HTML/JS player that does almost everything Flash did.
Unity also has a very good pipeline for building webgl targets. You can virtually ignore the platform concern until the very end, as long as you aren't being ridiculous with real time lighting and texture resolution.
SVG is a proper part of the browser. You get native text rendering, real links, real text selection, stuff like that.
Flutter is pure-canvas. You get no accessibility (unless you duplicate everything, in which case why even bother?), fake links which don’t behave properly, incorrect text rendering, megabytes of overhead, slow startup, &c.
I have used an LLM to write code in web servers to generate data plots using SVG embedded directly in web pages. This bypasses the need for PNG generation, Javascript for rendering a plot, and also the need for a plotting library. You can see two examples in the gist d29164051477ce1b2b95b788297a1932.
Though Stylus Labs’ site is not pure SVG, but a collection of SVGs embedded in an HTML container, which makes life quite a bit easier (applying a page background and embedding a video iframe are easier, and proper sizing and centring the column is not otherwise possible without scripting).
* 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...
[1] https://www.masswerk.at/6502/6502_instruction_set.html#stack
- smaller file sizes
- dark mode
- readable text
- selectable text
(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.)
It’s way undervalued and rarely gets updates.
https://gionkunz.github.io/chartist-js/
I wrote a small graphing library for mine [1], but it has limitations.
[1] https://coffeespace.org.uk/projects/sound-source-delta.html
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.
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.
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.
Though it'd discourage anyone to run off with this idea.. b/c SVGs are unfortunately kinda janky
My top 3 issues are:
- not even overly complicated SVGs, especially with text, will render notably different in different browsers (and renderers like Batik/Inkscape/SalamanderSVG/etc). I have no idea why.. PDFs don't have this issue. While I haven't tried, but I don't think PDFs are as easy to generate programmatically as SVGs
- SVGs have completely broken linking. You can embed an <svg> inside another <svg> to reuse an element - but for some reason it's limited to a link depth of 1! So you can't link an <svg> that links an <svg>. So SVG aren't safely composable - which drives me nuts.. (ex: making a large display panel in SVG that has subcharts)
- Maybe minor.. but tooltips in SVG (which are super handy.. for instance in plots to display additional info about a data point) don't work when the SVG is in an HTML page. They seem to only work when you open SVG in a separate tab.
More abstractly they just have very weird perf issues. Some mildly complex SVGs take GBs of RAM and 1> min to render. But it's unclear which parts are performance sinks.
[1] https://www.damninteresting.com
If you aren't careful they can be used for XSS and all kinds of nasty stuff.
They are also super useful in general though despite that.
The only thing that separates it from html and css is that html and css biases towards website styled stuff. HTML is designed for text boxes and that kind of stuff while svgs bias more towards a neutral drawing medium: shapes and vectors.
So because it’s more neutral you can even make a html engine from svg if you so wanted.
They do get indexed by Google, and we take some extra steps to ensure usability.
A while back I used a giant interactive SVG as the UI for a site I was prototyping, albeit wrapped in a normal HTML page. It was easy to set up and worked reasonably well, but I found that in Firefox performance started to degrade beyond a few thousand elements and so converted everything (except some accessibility features) to use a canvas instead. (The core of the old version is still deployed here if you want to see how far you can push it: https://freeclimbs.org/wall/demo/edit-set )
I realize it's far from a best practice and even explicitly stated as a bad idea somewhere in the SVG spec, but the idea of a document editor where you can individually position each and every character and make detailed, individual glyphs natively without loading fonts is interesting to me.
Are there any examples of this? Or perhaps different (better) approaches to a document editor with the advantages I said above?
• Caret mode (F7) doesn’t work at all.
• Triple click selects all the text on the page, rather than just that of a single <text> element as I’d have expected (in which model you’d use <text> for a paragraph and <tspan> for its lines, and thus get the normal triple-click behaviour).
• Click and drag on a text link starts selection or drags the already-selected text, rather than dragging the link so you can drop it in a new tab or such. And if you mouse up on the same link (regardless of having left it), it activates.
• If you start a selection, it is only updated while you’re moving over text. Drag past the end of the line, then down, and it should select more text, but it only actually will when you move back over text.
• If text is selected, clicking outside text doesn’t clear the selection. (Probably the same root cause.)
• Shift+Up and Shift+Down select to the start or end of the containing <text> element, rather than operating linewise. (Because there’s no such thing logically, it’d require heuristic work. Or for people to implement flowed text, like Inkscape did but sadly then it was pulled out of the spec for some reason.)
There are also a couple of issues specific to this document:
• Document order is not sensible. For example, it goes title, then side nav title, then footer, then body text, then “Home”, then side nav contents, then magic keyword. But this does show a broader problem: in HTML it’s not the easiest to get stupid document ordering (possible, but you have to go a little out of your way), but in SVG it will happen unless you’re careful.
• Also likely to happen unless you’re careful: multiline text sometimes lacks the trailing spaces necessary to separate words once the line break is ignored (since there’s no such thing as a line break in SVG 1.1, only a shifted cursor position). For example, “Inkscapefor” fails, whereas “willing to” succeeds.
—⁂—
Chromium is interesting. Supports caret browsing (+), Up/Down do something weird (−), triple click only selects that <text> element (+), you can’t start a text selection in a link (±), but you can’t drag the link either (=), and while selecting, any time the pointer is not over text, it’ll shift that selection boundary to something like the start of the document (−), except it’s not actually the start because it excludes the title text for some reason.
Any time you drag over space between lines, it selects something else.
Yet another example of how maddening it still is when designing websites that have the same experience regardless of how it is viewed.
https://www.google.com/search?q=svg.nicubunu.ro seems to surface it, with text; https://www.google.com/search?q=site:svg.nicubunu.ro gets the title, but no more text. I’m curious how it decided what the title was. I wonder if they have some kind of “choose the largest text” heuristic if a title is missing.
https://duckduckgo.com/?q=svg.nicubunu.ro and https://duckduckgo.com/?q=site:svg.nicubunu.ro don’t show a result.
It was so nice and unlocked so much creativity among early web developers. unfortunately Apple contributed to its demise
[1] https://www.cocos.com/en/cocos2d-x
[2] https://godotengine.org/
[3] https://pixijs.com/
[4] https://phaser.io/
SVG is a proper part of the browser. You get native text rendering, real links, real text selection, stuff like that.
Flutter is pure-canvas. You get no accessibility (unless you duplicate everything, in which case why even bother?), fake links which don’t behave properly, incorrect text rendering, megabytes of overhead, slow startup, &c.
There are some very nice showcases at the bottom of the page. For example, 2021: https://2021.svija.love/
Previously featured on HN: https://news.ycombinator.com/item?id=33518845 [Show HN: All-SVG websites with complex animation]
In-what? Unhappiness with a statistical outcome? Discouragement with events in one's home state?
Based on the many other uncorrected typos in the example SVG, I suspect that Inkscape has everything but a spell checker.
Apropos, Inkscape is a big app and does practically everything.