Even though the article is mostly talking about visualizations, but I thought I'd share that I did at one point build a dance choreography software that renders the UI entirely SVG. I was surprised as to how well that worked.
If you're curious, it's called StageKeep, and you can find it here. https://stagekeep.com/
The original project used React Three Fiber, but refactored it to SVG for reasons I don't quite remember. I was inspired by signed distance functions, and the fact that one function could have such an outsized visual effect. Although the software doesn't use SDFs, but I like the idea of atomic functions that accepts some input, and outputs SVG.
- cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how? Photoshop solved this long time ago - it saves both text and its rendering, so the text can always be rendered.
- browsers do not publish, which version and features they support
- may contain Javascript and references to external resources, which makes it difficult to view in a secure, isolated environment
One of solutions is having two SVGs: author version, which you edit in Inkscape and which uses Inkscape-specific extensions, and published version, which is generated from the first, that uses only basic features and has text converted to curves.
"""
In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed.
"""
I do like seeing larger labs/companies releasing research full of SVGs. In recent memory, I quite liked this from NVIDIA:
Two years ago I re-vamped my "Spurious Correlations" side project, which is mostly just a bunch of charts. However, I couldn't find a charting software I liked that would display clean, simple visuals with the constraints I wanted. (I had used pCharts and HighCharts in the past, but didn't like charting in Javascript or PHP.)
I decided to "roll my own" and write Python scripts that outputted SVG markup. I was worried this would go about as well as every other "roll your own" project does, but was pleasantly surprised. It is surprisingly easy to output reliable, good-looking SVG graphics using Python. If you are making a chart, everything is just math.
The infinite scalability is almost just a happy upside to the simplicity of creating the visualizations, which is annoying in raster format. It made me like SVG even more.
The first Distill publication[0] made tasteful use of minimal interactivity through JavaScript/d3.js[1] on top of SVGs. Many of the illustrations were initially drawn in GUI editors.
(Outstanding work by Shan Carter; it’s what I first saw of his style and it’s what made me want to join his team.)
Around 15 years ago, I built a barbecue controller. This controller had four temperature probes that could be used to check the temperature of the inner cooking chamber as well as various cuts of meat. It controlled servos that opened and closed vents and had a custom derived PID algorithm that could infer the delayed effects of oxygen to charcoal.
Anyway, of relevance to this thread is that the controller connected to the local wireless network and provided an embedded HTTP server with an SVG based web UI that would graph temperatures and provided actual knobs and dials so that the controller could be tweaked. SVG in the browser works nicely with Javascript.
Author here: I've just made a ninja edit of the post as it didn't really make clear a quite important point - the SVG is literally 20 years old, and still works, astonishingly. I'm not sure much else I wrote around the time would still work without some editing!
Ages ago, when doing the instructions for the opensource CNC Shapeoko v2 it became necessary (after the project was featured w/ a full page in _Popular Mechanics_ magazine to cater to users who could not visualize as well as the early adopters were able to, so the diagrams were made interactive:
Used to be if that was opened in a web browser one could click on the parts list to show/hide or highlight/unhighlight the matching items in the diagram.
My day job involves building dashboards, and SVGs have been invaluable for crisp icons and graphs... the portability across sizes is a blessing, but some of the more exotic filter effects still fail in certain browsers.
ALSO I've run into security reviews that flag inline SVGs because they can embed scripts... would love to see more tooling to lint and sanitize them before deployment.
BUT seeing a two-decade-old vector still render correctly gives me confidence that the core spec is solid.
I once solved a machining problem using SVG and a bit of javascript and python.
I was prototyping an orrery. It involved cutting out a lot of ad-hoc gears and frame bits on my CNC out of a sheet of brass. It was relatively easy to generate the g-code for the individual parts using fusion360, but then it was a lot of faff to zero the machine such that it cut the part from a fresh part of the brass sheet without wasting too much metal in between the parts. It involved a lot of guesswork, and eyeballing. And even with that there was a lot of brass “wasted” between the parts especially since you could only move your part in x-y but not easily rotate it.
As a solution I wrote a python script which converted the g-code into svg, and a simple one page website where i could drag the svg around and rotate it on a visual representation of the sheet. Once i found a good safe spot for it to be cut the page told me the x,y, theta coordinates for it. And then with a separate python script i could transform the g-code using the coordinates and rotation. This way the svg renderer was doing the heavy lifting of visualising the cutting paths, and i only needed to concentrate on the relatively easy transforms.
>They are supported on just about every device and platform
Except they aren't. I recently used a simple SVG in a background and Safari wasn't able to render it properly so after trying lots of different things I gave up and used different sizes of raster images instead.
This feels a little bit like discovering frontend software development? I guess we're done with the trend of being scared of bundling features and running them in the browser close to the user with JavaScript.
I notice one issue in SVG support in browsers that make it pretty unusable. When multiple polygons connect by edge, renderers alpha-blend their edges as if they are in general position, causing visible 'seam'. This is well-known problem in 2D graphics, usually handled by explicit selection of blending functions, but i cannot find anything about how to fix it in SVG.
I once built a music game that basically ran entirely on SVG. We hacked Musescore to attach the same UUID to both the note head in SVG and the MusicXML object in two different output modes, and then used that to synchronise the sheet music scrolling with a MIDI stream. If you're interested you can see it in action in our failed Kickstarter video from like eight years ago: https://www.youtube.com/watch?v=vgbB5Q4-dgY
I use ChatGPT to compress SVGs, in particular QR codes. Many QR code SVG generators produce inefficient SVGs, and conventional SVG compressors often lack the understanding required for some compression techniques. ChatGPT can replace alignment indicators with <use> elements.
Is there a way to embed the data encoded in the QR code directly within the image? This would allow the data to be parsed directly by the browser, eliminating the need for computer vision to decode it again. Going further, for web images QR codes could be efficiently encoded and rendered by the browser.
I remember an employee of mine, who was possibly the best engineer I ever knew, wrote up a specification document for his own vignetting algorithm, in Postscript.
The algorithm provided a 100X performance improvement over the classic Monte Carlo stuff that Tokyo had written.
The charts in the document were executable Postscript, running his algorithm.
That got the attention of the Ph.Ds in Tokyo. He was a high school-educated neurodivergent.
This way - even if the user changes themes, the colors of the image will be consistent with whatever theme is currently active. Also - the loading time is near-instant since we don't need to fetch the img file for the blog post image - just render the svg.
Is there a 3D equivalent (technical or spiritual) of SVG? I've been working on a CAD visualizer, and I'm looking for something lightweight that I can use to build up representative changes to cad models without having to do a full loop through the CAD application, pull a full .step export, and visualize that.
SVGs will work nicely for showing 2d sketches, but I'm hoping for something similar for the models themselves, without the slowdown of having to use the underlying CAD software for visualization.
I recently found out that it is surprisingly hard to convert an SVG file that consists of series of line segments into a list of those line segments in Python.
I tried with ChatGPT and Claude but both were not able to find a solution that respects the entire specification, especially transforms.
Initially, my expectation was that there must be a library for this kind of thing, but alas.
SVG's are so fun! The amount of logic you can put into an SVG is absolutely wild given what they're generally used for. My desktop wallpaper uses embedded JS to create a random Barnsley fern fractal every time the system starts, so it's different every time. The only problem is that only browsers have the full SVG spec support I needed to get it to work correctly, but that's nothing that systemd and puppeteer can't fix.
A few years ago I learned just enough d3 to show an interactive 2D lollipop graph. Later I learned just enough SVG to get a small diagram out for a college class. I think going back if I were to redo that first interactive graph I'd probably just do it in raw SVG.
I remember making an .svg spirit thermometer that polled our local weather station and scaled the red bar accordingly some 12 years ago. A nice gimmick but I didn't see any real use for it. We joked about making a single-image SCADA monitor screen.
I love seeing old formats hold up this well. SVG surviving 20 years of browser evolution is a pretty strong argument for “boring tech” done right.
It makes me wonder why we don’t see more research papers ship with fully self-contained interactive SVGs today — the tooling and browser performance are better than ever.
This is going to really transform some data visualization things I've been thinking about. I've always loved SVG since working with Illustrator and Inkscape back in the day, but I didn't realize how much it could tie in with the modern web and interactivity. Thank you!
An SVG is all you need
(jon.recoil.org)335 points by sadiq 11 December 2025 | 144 comments
Comments
If you're curious, it's called StageKeep, and you can find it here. https://stagekeep.com/
The original project used React Three Fiber, but refactored it to SVG for reasons I don't quite remember. I was inspired by signed distance functions, and the fact that one function could have such an outsized visual effect. Although the software doesn't use SDFs, but I like the idea of atomic functions that accepts some input, and outputs SVG.
- cannot wrap text
- cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how? Photoshop solved this long time ago - it saves both text and its rendering, so the text can always be rendered.
- browsers do not publish, which version and features they support
- may contain Javascript and references to external resources, which makes it difficult to view in a secure, isolated environment
One of solutions is having two SVGs: author version, which you edit in Inkscape and which uses Inkscape-specific extensions, and published version, which is generated from the first, that uses only basic features and has text converted to curves.
""" In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed. """
I do like seeing larger labs/companies releasing research full of SVGs. In recent memory, I quite liked this from NVIDIA:
https://research.nvidia.com/labs/dbr/blog/illustrated-evo2/
I decided to "roll my own" and write Python scripts that outputted SVG markup. I was worried this would go about as well as every other "roll your own" project does, but was pleasantly surprised. It is surprisingly easy to output reliable, good-looking SVG graphics using Python. If you are making a chart, everything is just math.
The infinite scalability is almost just a happy upside to the simplicity of creating the visualizations, which is annoying in raster format. It made me like SVG even more.
(Outstanding work by Shan Carter; it’s what I first saw of his style and it’s what made me want to join his team.)
[0] https://distill.pub/2016/augmented-rnns/ [1] https://github.com/distillpub/post--augmented-rnns/blob/mast...
Anyway, of relevance to this thread is that the controller connected to the local wireless network and provided an embedded HTTP server with an SVG based web UI that would graph temperatures and provided actual knobs and dials so that the controller could be tweaked. SVG in the browser works nicely with Javascript.
Like for QR Code, precise maps or +100 pixels wide squares. More than 100 "DOM" elements and it will take multiple seconds to show.
The animations also are slow too, compared to canvas, plain CSS or Lottie but nothing very cursed, it's mostly fine.
https://github.com/shapeoko/Docs/blob/gh-pages/content/tPict...
Used to be if that was opened in a web browser one could click on the parts list to show/hide or highlight/unhighlight the matching items in the diagram.
Done using Inkscape if memory serves.
ALSO I've run into security reviews that flag inline SVGs because they can embed scripts... would love to see more tooling to lint and sanitize them before deployment.
BUT seeing a two-decade-old vector still render correctly gives me confidence that the core spec is solid.
I was prototyping an orrery. It involved cutting out a lot of ad-hoc gears and frame bits on my CNC out of a sheet of brass. It was relatively easy to generate the g-code for the individual parts using fusion360, but then it was a lot of faff to zero the machine such that it cut the part from a fresh part of the brass sheet without wasting too much metal in between the parts. It involved a lot of guesswork, and eyeballing. And even with that there was a lot of brass “wasted” between the parts especially since you could only move your part in x-y but not easily rotate it.
As a solution I wrote a python script which converted the g-code into svg, and a simple one page website where i could drag the svg around and rotate it on a visual representation of the sheet. Once i found a good safe spot for it to be cut the page told me the x,y, theta coordinates for it. And then with a separate python script i could transform the g-code using the coordinates and rotation. This way the svg renderer was doing the heavy lifting of visualising the cutting paths, and i only needed to concentrate on the relatively easy transforms.
github: https://github.com/davefowler/markdown-svg playground: https://markdown-svg-production.up.railway.app
Except they aren't. I recently used a simple SVG in a background and Safari wasn't able to render it properly so after trying lots of different things I gave up and used different sizes of raster images instead.
Is there a way to embed the data encoded in the QR code directly within the image? This would allow the data to be parsed directly by the browser, eliminating the need for computer vision to decode it again. Going further, for web images QR codes could be efficiently encoded and rendered by the browser.
The algorithm provided a 100X performance improvement over the classic Monte Carlo stuff that Tokyo had written.
The charts in the document were executable Postscript, running his algorithm.
That got the attention of the Ph.Ds in Tokyo. He was a high school-educated neurodivergent.
We use SVGs on https://typequicker.com/press for the blog post hero images.
This way - even if the user changes themes, the colors of the image will be consistent with whatever theme is currently active. Also - the loading time is near-instant since we don't need to fetch the img file for the blog post image - just render the svg.
SVGs will work nicely for showing 2d sketches, but I'm hoping for something similar for the models themselves, without the slowdown of having to use the underlying CAD software for visualization.
I tried with ChatGPT and Claude but both were not able to find a solution that respects the entire specification, especially transforms.
Initially, my expectation was that there must be a library for this kind of thing, but alas.
Still, the one-SVG-to-have-it-all might be an overkill for a web page. Both semantically and syntactically...
As such I think it's not a good idea for a document that should have a large audience.
But can it read email? https://www.laws-of-software.com/laws/zawinski/
Simple? No. SVGs are not simple. If they were simple they weren't so capable.
https://www.cloudflare.com/cloudforce-one/research/svgs-the-...
https://news.ycombinator.com/item?id=20980837
TLDR:
- SVG image files: powerful like HTML
- Supported widely in browsers
- Designer tools make SVGs
- SVGs are written in a language
- LLMs are great at manipulating language
- Designers can collaborate interaction into life