An Svg Is All You Need
Key topics
The notion that "An SVG is all you need" has sparked a lively discussion about the versatility of SVG files in creating interactive web experiences. Commenters are exploring the potential of combining SVGs with JavaScript to catch keypress events and edit the SVG in situ, effectively recreating the interactivity of Flash. While some are enthusiastic about using AI to manipulate SVGs, others are skeptical about the capabilities of large language models (LLMs) in this regard, although they acknowledge that SVGs can be more easily edited using specific commands. The conversation is highlighting the long-standing value of SVGs in transforming web experiences, particularly in data visualization, with some commenters drawing parallels to earlier innovations like Distill publications.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3m
Peak period
85
0-12h
Avg / period
21.3
Based on 149 loaded comments
Key moments
- 01Story posted
Dec 11, 2025 at 2:25 PM EST
23 days ago
Step 01 - 02First comment
Dec 11, 2025 at 2:28 PM EST
3m after posting
Step 02 - 03Peak activity
85 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 18, 2025 at 2:16 PM EST
16 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
E.g. here's a sample I forked following the mouse using <svg> with <script> also inside https://codepen.io/zamadatix/pen/emZXZKx?css-preprocessor=sc...
- https://mlu-explain.github.io/neural-networks/
- https://www.nytimes.com/spotlight/graphics
- https://pudding.cool/
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.
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.
Why? svgomg.net exists, uses far fewer resources, and is going to give you much better results.
https://jakearchibald.github.io/svgomg/
SVGs are XML so technically, yes, you can just embed your visually encoded payload data with namespaces attributes and elements. If you don't want to use namespaces, you can use off-canvas texts, hidden/opacity=0 texts or even XML comments. You can even use the regular metadata section of SVGs. You can make the whole QR code within the SVG a clickable link.
So a SVG you authored 20 years ago for some browser will likely work everywhere today.
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.
Did you see?:
https://github.com/cloudflare/svg-hush
Sanitisation is one of two possible defences, the other being script execution controls or sandboxing. E.g., if you serve an SVG on a web server, set a Content Security Policy header for all your images that simply denies all scripting. You can also run it from a dummy domain ('origin') with nothing valuable on it (like how domains such as googleusercontent.com and githubusercontent.com are being used)
For sanitisation, DOMPurify is the only widely used and tested library that I know of. It could use more bindings for other languages but if you can call into it, it can go in your deployment pipeline: https://github.com/cure53/DOMPurify (disclosure: I've worked with some of the people at Cure53, but not on this project)
You can also combine the approaches for defence in depth
I believe Slack is an electron app so it might be easy to implement.
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.
This was done for a friend of mine who made an art installation that projected like some 50x20 (can’t remember exactly) of these images in a grid on a wall, for perpetual chess madness.
The number of chess SVGs a laptop’s browser was able to run simultaneously did feel suprisingly low, but luckily it was enough for that particular piece of art.
He said he used ipads as renderers. And even one grid may have looked different back in the day than that page now, as the font might be different. The SVG just uses system fonts and the chess pieces are just unicode characters.
Is there a way to control the speed. When I load a single SVG into browser, it runs through the whole game in a flash. (Edge shows animation; chrome and firefox show static image for me)
You can increase COMP_MOVE_TIMEOUT (which is now 1 millisecond) to, say, 100 milliseconds.
RESET TIMEOUT defines how long the game is paused after game is finished to let the viewer to see the result, and NEW_GAME_START_TIMEOUT defines how long to wait before doing the first move when a new game is started.
The static image may be because of some browser security mechanisms; served as raw from GitHub the SVG is not animated for me either on Firefox, but when I download the SVG and view it from local drive in Firefox, it works. (It did work when served from GitHub at some point in history, though.)
Is embedding intelligent logic inside of SVGs for animation a common thing -- feels very novel to me. Kudos for the idea and execution!
I am wondering if it is possible to push it even further and bring more and more creative logic -- say to create some unique patterns / designs etc that render differently each time. Say a swirling ripples animation that keeps changing over time but never feels like it is "pre-recorded".
Also, can animated SVGs be embedded in powerpoint and the like -- so we get crisp vector animated design elements in a compact portable format?
I do worry that this can also open some possible attacks -- malicious URLs in a dynamically generated QR, for example.
""" 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/
Without interactivity, postscript is vector graphics too.
It's if we had the .docx format but MS Word was read-only. You would have to create the XML and zip it yourself, to be then rendered by Word. That's effectively how I see HTML+js in browsers.
[1] Paper: https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/clouds...
[2] Figure 1: https://tum-dis.github.io/cloudspecs/?state=N4IgzgjgNgigrgUw...
The idea of being able to view and parse the dataset in different ways is interesting though, effectively allowing readers to interpret the experiment's resulting dataset from different angles than the author published.
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.
It's on my list to revisit in the future. At this point, most of the patents are coming up on expiration, and it would make for a great open source project. Hardware has gotten much better over the subsequent years; there are nicer lower power solutions with integrated Bluetooth LE as well as other low power wireless technologies.
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.
Sorry that's not more useful and explicit, it was a while back and never went anywhere.
But there seems to be a lot of SVG specific tooling and code to do this in python?
Eg: https://github.com/RaubCamaioni/svgpath
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.
I wish I was a dancer.
That said, the founder who hired me to work on this liked the fact that during the interview, when asked "what do you know about dance", I responded "I used to crip walk when I was in high school", so I was the top choice just for that, haha.
Then Flash just died without being replaced by anything
If they had been willing to invest the resources needed to make it both performant and, most importantly, secure, there's a much better chance that it would have survived—it might even have been enough for Jobs to be willing to have it work on the iPhone. (Maybe.)
Too many people lamenting how the death of Flash ended a thriving ecosystem of games and other art forms forget that Flash was also a huge resource hog, one of the #1 sources of crashes on many systems, and an absolutely massive vector for malware. I'd love to see some statistics on just how many infections were enabled by Flash, and how fast that declined once it stopped being a requirement to browse large chunks of the web.
And don't forget, either, that Flash wasn't originally an Adobe product: they took it over when they bought Macromedia, eliminating their biggest competitor and guaranteeing their monopoly. I wasn't really paying that much attention to the space, but it wouldn't surprise me if under Macromedia, it was getting better and more frequent updates.
I've been using SVG for years for various purposes (though, admittedly, mostly static graphics) and I can't complain.
Around 2010, I did experiment with things like Silverlight and SVGs. SVGs was OK, but the performance quality was not there. It might be a lot better now.
I would LOVE to see this feature: pass it a video, get a formulated choreography based on that video. For example, take a Project21 or Avantgardey video, do some AI/ML voodoo, import their choreography.
Think that'd be possible?
github: https://github.com/davefowler/markdown-svg playground: https://markdown-svg-production.up.railway.app
Anyways, impressive, but what I’d really love to see is flexbox for SVG ;)
https://www.cloudflare.com/cloudforce-one/research/svgs-the-...
Odd thing to say. Everything on a computer is "essentially code", executable or not.
And as a side note: Cloudflare itself is considered harmful
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.
(There was some justification in terms of 'Oh, a binary format like PDF is more space efficient.' But PDF never really was more efficient than compressed PS.)
It is extremely useful to have a full programing language as a file format, though.
I miss macOS’s Preview.app auto-converting PS to PDF when double-clicked. It was a way to easily distribute a document that could randomize question orders each time it opened, print multiple bingo cards from a single file, etc.
The stack-based and reverse Polish notation thing was also fun.
Btw, doesn't PDF include Javascript these days? So you can still randomise stuff at view-time in a PDF. See https://th0mas.nl/2025/01/12/tetris-in-a-pdf/
But it was not all that good as a way to send documents to be printed elsewhere. Postscript files were in some ways too dependent on the printer they targeted, so the person creating the PS file had to know too much about the printer that would be used to print it: its resolution and optimal halftone screen frequencies, media sizes, etc. With high-resolution output on photographic film costing around $10 per foot, mistakes could be expensive as well as time-wasting.
Fonts could also be a problem. Ideally, the PS file would contain all the fonts it required but this did not fit very well with the terms of most font licenses. And some applications would include a copy of every font used once on each page on which it was used. This was in line with Adobe's recommended Document Structuring Conventions and had the advantage of making pages within the file independent of one another, but for documents with hundreds of pages, this could add up fast and make the PS file literally hundreds of times larger than if all the fonts were included just once. With small storage media and slow network links, this was a real problem.
The "P" in PDF is for portable, and these are the problems it solved. Unlike a PS file, a PDF file is not targeted for a specific printer model, and most font licenses allowed the licensee to include subsetted fonts in PDF files. I personally prepared PS files for a few thousand books to be printed at various places around the US and later, PDF files for thousands more. There is no comparison: PDF was and is better in every way for this purpose.
However we can imagine a world where some relatively minor evolutions in PS would have moved it into the right trajectory.
(Thanks for all the historic details!)
It's from the creator of D3 and it's much easier than using raw D3. I've been using it outside the Observable platform for debug charts and notebooks, and I find its output crisp and its API very usable.
It doesn't try to have all the bells and whistles, and I'm not even sure if it has animations. But for the kind of charts you see in papers and notebooks I think it covers a lot.
We as an industry need to get rid of this fear of creating stuff.
- 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
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.
Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.
For better or worse, CSS parsing and WOFF support are both mandatory in SVG 2.[0][1] Time will tell whether this makes it a dead spec!
[0] https://www.w3.org/TR/SVG2/styling.html#StylingUsingCSS
[1] https://www.w3.org/TR/SVG2/text.html#FontsGlyphs
This is possible, but only in the stupid way of using a `<foreignObject>` to embed HTML in your SVG. SVG 2 fixes this by adding support for `inline-size`[0], so now UAs just need to… support that.
> - 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?
Somebody did think of it. SVG 1.1 added the `<font>` element;[1] SVG 2.0 replaced this with mandatory WOFF support.[2] A WOFF is both subsettable and embeddable using a data URI, and is supported by all the browser UAs already.
> - browsers do not publish, which version and features they support
It should be possible to use CSS `@supports` for most of this and hide/show parts of the SVG accordingly.[3] The SVG spec itself includes its own mechanism for feature detection[4], but since it is for “capabilities within a user agent that go beyond the feature set defined in this specification”, it’s essentially worthless.
There are obvious unsolved problems with SVG text, but they are more subtle. For example, many things one might want to render with SVG (like graphs) make more sense with an origin at the bottom-left. This is trivial using a global transform `scaleY(-100%)`, except for text. There is no “baseline” transform origin, nor any CSS unit for the ascent or descent of the line box, nor any supported `vector-effect` keyword to make the transformation apply only to the position and not the rendering. So unless the text is all the same size, and/or you know the font metrics in advance and can hard-code the correct translations, it is impossible to do the trivial thing.
There are other issues in a similar vein where scaling control is just ludicrously inadequate. Would you like to have a shape with a pattern fill that dynamically resizes itself to fill the SVG, but doesn’t distort the pattern, like how HTML elements and CSS `background` work? Good luck! (It’s possible, but much like the situation with text wrapping, requires egregious hacks.)
Some of the new `vector-effect` keywords in SVG 2 seem like they could address at least some of this, but those are “at risk” features which are not supported by UAs and may still be dropped from the final SVG 2 spec.
[0] https://www.w3.org/TR/SVG2/text.html#InlineSizeProperty
[1] https://www.w3.org/TR/SVG11/fonts.html
[2] https://www.w3.org/TR/SVG2/changes.html#fonts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
[4] https://www.w3.org/TR/SVG2/struct.html#ConditionalProcessing...
But this then loses the ability to select it as text—which, at least in Safari, is present with an SVG <text> element.
So either way you don't get full functionality.
- They often render differently in different browsers and other renderers. It's very frustrating to get consistent results (like a PDF). In complex diagrams I'd say it's basically impossible
- Renderers that are fast usually lack many features
- Nobody other than the browser seems to actually have all the features?
- You can link an SVG within an SVG (to make a lightweight composite image). But if you have two levels of indirection then all renderers I've tried will refuse to render the SVG
- Inkscape is basically the only good editor on Linux and it easily runs out of memory and crashes for complex images
- Complex SVGs eat all your RAM in Chromium (only marginally better in Firefox)
- Basic things like arrows from Inkscape will not render anywhere else
I still use SVGs all the time, b/c there are no good alternatives, but it's a crappy standard and I try to keep all my images/diagrams extremely simple
As such I think it's not a good idea for a document that should have a large audience.
You would need an interacting charting library that works with a keyboard and that is readable by a screen reader.
Also note that different browsers might render and print the same SVG differently, which is not ideal for a print-oriented format.
But can it read email? https://www.laws-of-software.com/laws/zawinski/
https://news.ycombinator.com/item?id=20980837
Still, the one-SVG-to-have-it-all might be an overkill for a web page. Both semantically and syntactically...
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 cuts 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.
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.
Simple? No. SVGs are not simple. If they were simple they weren't so capable.
Once I happened upon carto.net namely this: https://old.carto.net/papers/svg/samples/index.shtml#iact
I was absolutely sold on SVG.
now I find this: https://cartosvg.com/ which is mind blowing the capability and capacity, just the first example from link, really makes my day https://cartosvg.com/italia then the 2nd! It's compelling. I wish I could have built what i was trying to conceive building using OSC (Open Sound Control), but what i was setting out to do was ultimately brought into the world by Hexler's TouchOSC, i just wish somehow someone could have took VST to a unified front, and made it random controller populatable. impossible back then, yes. Today, different.
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.
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.
(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...