In the same spirit I have started building single page nanodjango +htmx apps hosted on railway, starting with, you guessed it, a Todo list app. No login needed.
The thing that matters for me when considering a new library is what it can do. Once I know that I can decide if it's worth learning how to use it at a code level.
In the case of JustHTML I've now been able to try it against a few different HTML documents, seen it do good pretty-printing, played with its CSS selector implementation and got a feel for its event-based streaming parser. I'm very impressed! I think I'll be using it in the future next time I need an HTML parser.
HTML tools are a good name. I called them something like "a local html file"
One problem I solved with this was a packer needed to scan a few (10-40) ids into his barcode scanner. It was not enough where pulling up their bulk-id-uploader program but also too tedious to go to some "number to barcode" website.
Turns out, barcodes can be made from a google font!
You can just display a number using that font. Then hooked up a for-loop that's progressed by pressing the space bar: paste in IDs, scan first, space, scan next, repeat.
Great timing - I've taken up vibecoding and picked personal tools with simple HTML/CSS/JS/python stack as the learning ground too.
Personal tools seem like a reasonable place for happy path vibecoding given small blast radius and LLMs can do that sort of static page in front of python backend really well.
I've also been surprised how much active learning I'm doing despite specifically not look at code. Between the need to spec things out carefully (plan.md) and fast iteration loop it's been a huge boost. Having the LLM look at a plan.md and suggest improvements has lead to a lot of "oh I didn't think about that" learning on architecture and user requirements link.
Presumably much of that learning boost is because I'm a hobbyist tier programmer, guessing professionals wouldn't experience the same since they learned this via manual coding trial & error over years.
One tool I'd really like to see in this format is a simple "turn the background of this PNG to transparent". Models still refuse to follow the instruction to create transparent backgrounds for logos they create, and I often have to look for other tools doing this as post-processing.
It's possible that this is too complicated for the "few hundred lines of js" code envelope, though.
Build transparent-png.html - a tool that lets you open any image and then click on colors within that image to make them transparent - showing a preview of the resulting PNG against a checkerboard pattern and optional against other selected background colors below, plus a download PNG option
It should also accept pasted images
Really enjoyed this, interesting read as always! It reminded me of Google Labs’ recent GenTabs project [1], and also of a recent ACM paper on user-assembled LLM-mediated tools from web content [2]. Feels like similar concepts are emerging in multiple places, all centered around lightweight intent-driven tools rather than traditional apps, which I think makes a lot of sense. Curious how this will evolve!
I think UIs will become more "generative" or "on demand". Not necessarily always generated anew, but assembled from pre-generated (reproducible) components, to suit a specific workflow.
I think especially in context of software that is complex and takes a long time to master, this could be the next breakthrough. Instead of paths-to-goal being buried in sequences of menus and config panels, workflow pathways would be invocable with plain language.
My tool collection [0] is inspired by yours, with a handful of differences. I'm only at 53 tools at the moment.
What I did differently:
Hosted on Cloudflare Pages. This gives you preview URLs for pull requests out the box. This might be possible with Github Pages but I haven't checked. I've used Vercel for similar projects in the past. Cloudflare seems to have the odd failed build that needs a kick from their dashboard.
Some tools can make use of Workers/Functions for backend processing and secrets. I try to keep these to a minimum but they're occasionally useful.
I have an AGENTS.md that's updated with a Github action to automatically pull in Claude-style Skills from the .skills directory. I blogged about this pattern and am still waiting for a standard to evolve [2].
I have a base stylesheet that I instruct agents to pull in. This gives a bit of consistency and also let's them use Tailwind, which they'd seem to love.
> "If you want to see the code and prompts, almost all of the examples in this post include a link in their footer to “view source” on GitHub. The GitHub commits usually contain either the prompt itself or a link to the transcript used to create the tool."
As if your steady stream of learning-in-public experiments and insights weren't generous enough. Seriously, massive kudos for sharing all the details.
Pretty nice. I've been using LLMs to generate different Python and JS tools for wrangling data for ontology engineering purposes.
More recently, I've found a lot of benefit from using the extended thinking mode in GPT-5 and -5.1. It tends to provide a fully functional and complete result from a zero-shot prompt. It's as close as I've gotten to pair programming with a (significantly) more experienced coder.
One functional example of that (with 30-50% of my own coding, reprompting and reviews) is my OntoGSN [1] research prototype. After a couple of weeks of work, it can handle different integration, reasoning and extension needs of people working in assurance, at least based on how I understood them. It's an example of a human-AI collab that I'm particularly proud of.
I’ve been making stuff like this for a while (pre-LLM days). They are great little side projects that tend to be useful without getting overly complex. While I’ve vibe coded a couple just to get something done that I needed, I tend to like to write them myself still, as I enjoy the process.
Been writing code since the 80's on my C64 and I love it but at this point, I will never write another line of code yet I will produce more code than I ever have! It's just as fun if not more.
Nice, I do this often enough that I created a bookmarklet to download an HTML file from clipboard after copying ChatGPT's code block.
I've also been using LLMs to create and maintain a "work assist" Chrome extension that I load unpacked from a local directory. Whenever I notice a minor pain point, I get the LLM to quickly implement a remedy. For example, I usually have several browser tabs open for Jira, and they all have the same company logo as the favicon, so my Chrome extension changes the favicon to be the issue type icon (e.g. Bug, Story, etc) when the page loads. It saves a little time when I'm looking for a specific ticket I've already opened.
> The alternative to CDNs is to use npm and have a build step for your projects. I find this reduces my productivity at hacking on individual tools and makes it harder to self-host them.
No. You can vendor these scripts & host them 1st party so you aren’t leaking data to these CDNs or risk users not actually getting the scripts. It isn’t like CDNs give you a performance boost anymore.
I also find that sticking to a single file makes coding agents perform better (fewer surgical edits, faster outputs, sensible changes, etc).
Not sure why, but the moment the file is split into files and subfolders, coding agents tend to do a lot more changes that what is absolutely necessary. That way a single html file wins!
Why not introduce a single shared CSS for style consistency? Not full CSS separation, each tool could still have its local CSS.
Things like styling buttons, responsiveness, and so on are better solved once.
A good rule of thumb is: if the shared CSS fails to load, page still fully works but it might be uglier (weird fonts, etc). That's a reasonable rule for proper isolation (tools remain simple to understand, code remains reusable, etc).
I love the idea of self-contained tools, but you're already using CDNs. Having a shared CSS wouldn't hurt and actually make the tools better.
I would go as far as having a shared JS too (same idea, works if it doesn't load).
Each spiral is mostly independent. You can go ahead and delete the shared CSS from the <head>, they still work and don't break funcionality. However, by having the shared CSS I made them consistent, made them friendly to phone users and so on.
Another useful pattern for certain types of app is to include a function that saves the HTML file to your local drive/memory as a new file - for example, if the app features user inputs like writing or drawing.
It's a little problematic to share an HTML file that you made or saved on your phone with other phone users directly, for example by sending via a messaging app: Android it's ok, but iOS won't open or save an HTML file sent in this way. Apparently there is a workaround to long press on the file to save it to your Files folder first.
This issue is relevant if your app's functionality includes the user changing the contents of the file and re-saving as a new file.
Unrelated, but I bought a walking pad, and because I often use it at home while working on the laptop, and I wanted a nice UI to track the speed/time etc, I just asked claude to do one:
Have been doing the same except I do use React because its my hammer haha. But I agree if you're not used to it then pure html/cs/js make sense.
https://www.hackyexperiments.com/micro
In the same spirit I have started building single page nanodjango +htmx apps hosted on railway, starting with, you guessed it, a Todo list app. No login needed.
https://web-production-1fc69.up.railway.app/
I just shipped a new one of these a few minutes ago (from my phone).
I found out about a new Python HTML parsing library - https://github.com/EmilStenstrom/justhtml - and wanted to try it out but I'm out without my laptop. So I had Claude Code for web build me a playground interface for trying it out: https://tools.simonwillison.net/justhtml
It loads the Python library using Pyodide and lets you try it out with a simple HTML UI.
The prompts I used are in this PR: https://github.com/simonw/tools/pull/156
Serious question. How do you "try out" a library if somebody else (or something else) is writing the code?
Thank you.
The thing that matters for me when considering a new library is what it can do. Once I know that I can decide if it's worth learning how to use it at a code level.
In the case of JustHTML I've now been able to try it against a few different HTML documents, seen it do good pretty-printing, played with its CSS selector implementation and got a feel for its event-based streaming parser. I'm very impressed! I think I'll be using it in the future next time I need an HTML parser.
HTML tools are a good name. I called them something like "a local html file"
One problem I solved with this was a packer needed to scan a few (10-40) ids into his barcode scanner. It was not enough where pulling up their bulk-id-uploader program but also too tedious to go to some "number to barcode" website.
Turns out, barcodes can be made from a google font!
https://fonts.google.com/specimen/Libre+Barcode+39
You can just display a number using that font. Then hooked up a for-loop that's progressed by pressing the space bar: paste in IDs, scan first, space, scan next, repeat.
Great timing - I've taken up vibecoding and picked personal tools with simple HTML/CSS/JS/python stack as the learning ground too.
Personal tools seem like a reasonable place for happy path vibecoding given small blast radius and LLMs can do that sort of static page in front of python backend really well.
I've also been surprised how much active learning I'm doing despite specifically not look at code. Between the need to spec things out carefully (plan.md) and fast iteration loop it's been a huge boost. Having the LLM look at a plan.md and suggest improvements has lead to a lot of "oh I didn't think about that" learning on architecture and user requirements link.
Presumably much of that learning boost is because I'm a hobbyist tier programmer, guessing professionals wouldn't experience the same since they learned this via manual coding trial & error over years.
Great work, Simon -- thanks for sharing!
One tool I'd really like to see in this format is a simple "turn the background of this PNG to transparent". Models still refuse to follow the instruction to create transparent backgrounds for logos they create, and I often have to look for other tools doing this as post-processing.
It's possible that this is too complicated for the "few hundred lines of js" code envelope, though.
Running this now...
Here's what I got (from Opus 4.5 in Claude Code for web via the Claude iPhone app): https://tools.simonwillison.net/transparent-pngReally enjoyed this, interesting read as always! It reminded me of Google Labs’ recent GenTabs project [1], and also of a recent ACM paper on user-assembled LLM-mediated tools from web content [2]. Feels like similar concepts are emerging in multiple places, all centered around lightweight intent-driven tools rather than traditional apps, which I think makes a lot of sense. Curious how this will evolve!
[1] https://labs.google/disco
[2] https://dl.acm.org/doi/10.1145/3706598.3713285
I think UIs will become more "generative" or "on demand". Not necessarily always generated anew, but assembled from pre-generated (reproducible) components, to suit a specific workflow.
I think especially in context of software that is complex and takes a long time to master, this could be the next breakthrough. Instead of paths-to-goal being buried in sequences of menus and config panels, workflow pathways would be invocable with plain language.
Thanks Simon!
My tool collection [0] is inspired by yours, with a handful of differences. I'm only at 53 tools at the moment.
What I did differently:
Hosted on Cloudflare Pages. This gives you preview URLs for pull requests out the box. This might be possible with Github Pages but I haven't checked. I've used Vercel for similar projects in the past. Cloudflare seems to have the odd failed build that needs a kick from their dashboard.
Some tools can make use of Workers/Functions for backend processing and secrets. I try to keep these to a minimum but they're occasionally useful.
I have an AGENTS.md that's updated with a Github action to automatically pull in Claude-style Skills from the .skills directory. I blogged about this pattern and am still waiting for a standard to evolve [2].
I have a base stylesheet that I instruct agents to pull in. This gives a bit of consistency and also let's them use Tailwind, which they'd seem to love.
[0] https://tools.dave.engineer/
[1] https://github.com/dave1010/tools/tree/main/functions
[2] https://dave.engineer/blog/2025/11/skills-to-agents/
I love this pattern. I’ve been using it myself here: https://pseudosavant.github.io/ps-web-tools/
Create PDFs from images, a Wordle hint/solver, or a classic DVD screensaver. Lots of stuff.
> "If you want to see the code and prompts, almost all of the examples in this post include a link in their footer to “view source” on GitHub. The GitHub commits usually contain either the prompt itself or a link to the transcript used to create the tool."
As if your steady stream of learning-in-public experiments and insights weren't generous enough. Seriously, massive kudos for sharing all the details.
I am building platform which makes it easy to host this kind of app but it has own set of idiosyncrasy u have to adhere to.
https://github.com/blue-monads/potatoverse
Pretty nice. I've been using LLMs to generate different Python and JS tools for wrangling data for ontology engineering purposes.
More recently, I've found a lot of benefit from using the extended thinking mode in GPT-5 and -5.1. It tends to provide a fully functional and complete result from a zero-shot prompt. It's as close as I've gotten to pair programming with a (significantly) more experienced coder.
One functional example of that (with 30-50% of my own coding, reprompting and reviews) is my OntoGSN [1] research prototype. After a couple of weeks of work, it can handle different integration, reasoning and extension needs of people working in assurance, at least based on how I understood them. It's an example of a human-AI collab that I'm particularly proud of.
[1] Playground at w3id.org/OntoGSN/
If HTML tools could make network calls (CORS be damned), they could replace a huge portion of hosted apps.
I'm tempted to run a CORS proxy somewhere - maybe on Cloudflare Workers - but I'm nervous that any open proxy is liable to be abused.
I could do an authentication protected one that only I could access though...
I’ve been making stuff like this for a while (pre-LLM days). They are great little side projects that tend to be useful without getting overly complex. While I’ve vibe coded a couple just to get something done that I needed, I tend to like to write them myself still, as I enjoy the process.
Been writing code since the 80's on my C64 and I love it but at this point, I will never write another line of code yet I will produce more code than I ever have! It's just as fun if not more.
I really like the simplicity here (maybe because it mirrors my own approach). No build chain, no node_packages, no frameworks.
I wonder if packaging the results as web components would be the next logical step.
Amazing article with lots of useful info. Big kudos, Simon.
This really showcases the power of the single page apps and why web will be always ahead of native for this kind of Swiss Army Knife tools.
With LLMs, it gets ridiculously easy to “develop” (generate) those too.
It really is wild how quickly these things pop out - this one here took a couple of prompts, probably ten minutes from idea to shipping a working implementation: https://tools.simonwillison.net/pypi-changelog?package=llm&c...
Nice, I do this often enough that I created a bookmarklet to download an HTML file from clipboard after copying ChatGPT's code block.
I've also been using LLMs to create and maintain a "work assist" Chrome extension that I load unpacked from a local directory. Whenever I notice a minor pain point, I get the LLM to quickly implement a remedy. For example, I usually have several browser tabs open for Jira, and they all have the same company logo as the favicon, so my Chrome extension changes the favicon to be the issue type icon (e.g. Bug, Story, etc) when the page loads. It saves a little time when I'm looking for a specific ticket I've already opened.
> The alternative to CDNs is to use npm and have a build step for your projects. I find this reduces my productivity at hacking on individual tools and makes it harder to self-host them.
No. You can vendor these scripts & host them 1st party so you aren’t leaking data to these CDNs or risk users not actually getting the scripts. It isn’t like CDNs give you a performance boost anymore.
https://httptoolkit.com/blog/public-cdn-risks/
I wish vendoring was less of a hassle.
I'll vendor and self-host for my professional projects, but for these small experimental utilities I've stopped caring.
Great link.
I also find that sticking to a single file makes coding agents perform better (fewer surgical edits, faster outputs, sensible changes, etc).
Not sure why, but the moment the file is split into files and subfolders, coding agents tend to do a lot more changes that what is absolutely necessary. That way a single html file wins!
Why not introduce a single shared CSS for style consistency? Not full CSS separation, each tool could still have its local CSS.
Things like styling buttons, responsiveness, and so on are better solved once.
A good rule of thumb is: if the shared CSS fails to load, page still fully works but it might be uglier (weird fonts, etc). That's a reasonable rule for proper isolation (tools remain simple to understand, code remains reusable, etc).
I love the idea of self-contained tools, but you're already using CDNs. Having a shared CSS wouldn't hurt and actually make the tools better.
I would go as far as having a shared JS too (same idea, works if it doesn't load).
That's essentially what I did in https://alganet.github.io/spiral/ (also vibe coded).
Each spiral is mostly independent. You can go ahead and delete the shared CSS from the <head>, they still work and don't break funcionality. However, by having the shared CSS I made them consistent, made them friendly to phone users and so on.
Yeah, I've been thinking some kind of reusable styles or style guide might be a good idea at this point.
It's been fun collecting a bunch of inconsistent tool designs just to see how the different models behave, plus occasionally I go for something with a topical theme like https://tools.simonwillison.net/terminal-to-html or https://tools.simonwillison.net/new-yorker-style - but a little more consistency could be nice.
Another useful pattern for certain types of app is to include a function that saves the HTML file to your local drive/memory as a new file - for example, if the app features user inputs like writing or drawing.
It's a little problematic to share an HTML file that you made or saved on your phone with other phone users directly, for example by sending via a messaging app: Android it's ok, but iOS won't open or save an HTML file sent in this way. Apparently there is a workaround to long press on the file to save it to your Files folder first.
This issue is relevant if your app's functionality includes the user changing the contents of the file and re-saving as a new file.
Unrelated, but I bought a walking pad, and because I often use it at home while working on the laptop, and I wanted a nice UI to track the speed/time etc, I just asked claude to do one:
https://pastebin.com/5HRLh1G6
it does something like this
https://imgur.com/a/888BtpG
and connects through BLE