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.
These are great. Something you might find interesting is that you can expose a google sheet to have an interactive database. I have a map similar to yours, but with surf spots. Maybe defeats the point, but I find it handy
Edit: come to think of it, I should revisit it now that everyone can vibe code. The sheet was to allow people to add to it, now maybe easier for me to take a message and ask an agent to update the html directly
Couple of unsolicited comments: first is that on mobile, the featured badge sits on top of the right facing arrow. Second is that the bubble level seems to be upside down? The bubble sinks rather than floats at least on my pixel
Thanks for showing this! It’s cool, and I enjoyed reading through some of the code.
Note that I tried to use some of the regex tools that needed LLMs and got a rate limit error.
I was also heavy on these single-file HTML tools. My problem was not being able to sync the localstorage data between PC and smartphone. I made a paid service which did that automatically. It didn't take off unfortunately, and I am keeping it on maintenance mode because it has some amount of free users that rely on it.
For anyone interested, to achieve synchronization I basically just use the https://github.com/google/diff-match-patch lib and save the patches in a db for each version with a version id. Then there's a generic JS file that I inject to uploaded HTML files that monkey patches the localstorage methods and optimistically updates the localstorage at the same time sending the diff to the server to save to the db.
I wonder if you can hack a LocalStorage sync feature via ATProto PDS, since you can put arbitrary JSON records via /xrpc/com.atproto.repo.putRecord and not just Bluesky posts.
The only drawback I can think of is that all of your commits are broadcast on a megaphone to the network firehose, but encryption can alleviate that somewhat.
I am not familiar with it, but I was thinking about making an open source version of this, but using webRTC, to just directly allow peer-to-peer synchronization without a centralized server.
In this type of scenario there are a lot considerations to be made though, specifically since you can't use CRDT's to handle concurrent updates on the data you have to either 1) not allow offline use of the apps, 2) create a merge conflict resolving interface or 3) just overwrite all changes with the latest one.
Idk if people would be interested in this and I haven't been using my HTML tools for a while now, so it's just an idea, maybe someone else wants to work on.
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.
I'm a big fan of using this kind of thing at work. Rather than setting up a web server or packaging something into an installer, I just pop the bundled HTML file on a shared drive.
The CDN approach works, but I don't love depending on some third-party service just so your app continues working. Instead, I like using vite with vite-plugin-singlefile. This lets you package your JS and CSS into a single HTML: https://www.npmjs.com/package/vite-plugin-singlefile
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.
> 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.
I can only speak for myself and my not-quite two decades of professional experience, but yes pretty much!
It’s neat to see that sped up for others though with lower stakes, though it’s not quite the same unless you prompt your agent to question you back a lot (Claude is much better at this in my experience)
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.
Until vibe coding came along, the ergonomics of a library were no less important than its functionality. But I understand how LLM assisted coding changes that perspective.
Yes, I guess it would start showing advantage for complex ones.
The idea is interesting, shame there is nothing for full stack like this, something like opinionated fossil-scm setup - which already has project management built in (for llm to use for its dev progress); together with backend and runtime state squashed inside single sqlite so you can create/delete them independently without a fuss.
One thing I tend to do myself is use https://generator.jspm.io/ to produce an import map once for all base dependencies I need (there's also a CLI), then I can easily copy/paste this template and get a self-contained single-file app that still supports JSX, React, and everything else. Some people may think it's overkill, but for me it's much more productive than document.getElementById("...") everywhere.
I don't have a lot of public examples of this, but here's a larger project where I used this strategy for a relatively large app that has TypeScript annotations for easy VSCode use, Tailwind for design, and it even loads in huge libraries like the Monaco code editor etc, and it all just works quite well 100% statically:
Makes me wish there was a cross-platform equivalent to HTML Applications [1]. They were hell to develop at the time, but being able to create single-text-file tools with a browser UI, file system and network access, and app automation via COM was amazing
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.
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.
A lot of investment at some very large companies you know are trying to achieve this right now, and betting big on it. So far the lack of determinism when it is required gets in the way, but we’ll see: it feels surmountable.
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.
I made a heart monitor for very high heart rate https://github.com/SMUsamaShah/heart-rate which can be installed on phone as a PWA too. It could use some more polish, more features which I could do with an LLM again.
LLMs are generating app for an idea that can fit in few hundred lines of html/js. Had an idea that what if brushes were dithered in a painting tool and made a dithered painting tool. https://github.com/SMUsamaShah/dither-painter
These tools and code are ephemeral though. You don't need to use mine for example. Just ask the LLM of the time to implement the idea and in most cases it will work fine.
I've found a lot of success building in Alpine.js but I'm surprised that most people don't do this / don't like it. It makes managing reactivity a bit easier than full vanilla JS
I also started building similar tools in early 2025 and have built around 80 of them so far: https://tools.o14.ai/. Recently, I built a data viewer app (https://tools.o14.ai/excel-qa-review.html) where I can upload an Excel or CSV file containing chat queries and answers for quick manual review.
Reviewing data in Excel is painful, especially when answers are in HTML or Markdown, because you don’t get proper rendering. Building small, custom tools that reduce the friction of reviewing data makes life much easier and more pleasant. These days, I use Claude Code for Web to build most of these apps, and they are deployed on Vercel.
I love this idea! I've also been using LLMs to build tiny utilities and automations for myself, but instead of using HTML, I'm building them as:
- Shell scripts, AppleScripts, etc. that I trigger from Alfred
- Obsidian plugins
- The occasional Emacs Lisp function
They serve a similar purpose for me as OP's HTML Tools, in the sense that they let me automate a small part of my workflow that I wouldn't otherwise have automated. If I have to choose between writing AppleScript and just doing something manually, I'll pick doing something manually 100% of the time. But if I can just ask an LLM to write the automation for me and then test it in a bunch of different scenarios, the choice becomes much easier.
After reading this post, I really want to try moving some of my automations to the web. Using HTML/JS/CSS for some of these tools will let me solve a whole different set of problems. E.g. I could more easily build automations for the non-techy folks in my family instead of just keeping them to myself.
I used to dislike AppleScript but now I enjoy using it. The turning point for me was when I finally bit the bullet and read a book on the subject.
AppleScript’s human readable language lulls you in this false sense of security that you can wing it and everything will just work out. This is simply not the case, it is a very quirky language and it helps to read a book to get the right mental model.
The second thing that helped was getting AppleScript debugger from Late Night Software. They recently decided to no longer develop it and release it for free on their site. It’s worth getting if you haven’t done so already.
I've written a bunch of shell scripts like this too, but I've been focusing increasingly on web tech mainly because that way the same tools work on both my laptop and my phone.
The barcode font trick from valbaca is brilliant. I've done similar things with base64-encoded data URIs to make tools completely standalone - no network calls, no CDN dependencies.
One pattern I've settled into: keeping tools under ~200 lines of JS total. Past that threshold I start losing the ability to hold the whole thing in my head, and the main benefit of these tools is that you can open them in a text editor and understand everything immediately.
The CORS limitation that xnx mentions is real though. I've worked around it a few times by having tools accept paste-from-clipboard instead of fetching URLs directly. Less elegant but it keeps the tool self-contained and avoids the proxy problem simonw mentioned.
I've been building these for years. I think its a great entrypoint for new developers and can be incredibly useful at work for solving short term inconveniences or scripts that help automate some tasks.
I have a Vue3 started template I host at https://http://vue-template.spaghet.me/ and all I have to do is curl and I'm ready to go.
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
Nice, I'm proud I managed to nerd-snipe you :-) Thanks for taking the time.
Seriously, though, I think this solves a nicely framed simpler problem. I was thinking about a more general tool, but that's genuinely hard (you'll need heavy CV algorithms or a special ML model to detect what is background what what isn't).
To be honest, what you built here is probably sufficient anyway, because the models are better at obeying "create a white background" or "create a 0xffffff background" than "transparent", so this tool can post-process to what's needed.
When asked for "transparent", I've had a model generate a fake checkerboard pattern of gray colors to imitate how viewers render transparent areas :-) For this kind of nonsense, the transparent-png tool wouldn't do!
The best thing to say to an image model IME is "use a colour/chroma key background" and then it gives you green or blue or whatever depending on colours used in the image.
Dude, you are amazing. Maybe you should make a suggestion box. Then while you are sleeping, the AI could evaluate the suggestions, and if they are good, it could prototype the tool, and then you could review the prototypes in your waking hours before clicking the tool to production. :)
Slight correction: I'd only refer to it as a "Single-File Web App" if it has no external dependencies (where as the "HTML Tool" definition allows for external dependencies loaded from CDNs).
I wouldn't call either of these tools that either. Using View Source reveals that there's a pretty obvious build step and confronts you with massive minified blobs. There's no way a person is going to be able open that HTML as a "single file" in their text editor to pick up development where it was left off. (In that regard, the HTML tools in the linked post are closer to the definition, even when they're written to load a module from a CDN.)
Next evolution: UX should allow end users to build the prompt, and then the tool is generated and deployed at a random URL. Tool also keeps original prompt, so any user can customize into a new (random URL) tool page.
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!
Surprised AI studio isn’t recommended here - you can go from prompt->preview->deploy in like a couple seconds.
They have a library of sample apps you can edit but I wish they included the prompts and history to build each since I generally can’t get large apps to work - after a while the I’ll just produces more bugs as complexity grows. But I’m also a bad vibe coder and never read the code so entirely my fault :)
Ah I’ve only used that feature once actually I’ll have to try it, I was talking about the deploy on gcp button (but pointlessly not free compared to your github pages recco!)
> "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.
> 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.
This is what CDNs should be used for at this time—or for fetching the scripts to vendor. That’s fine, but recommending I don’t think is the best call since one folk’s experimental utility will inevitably get released into production—often not even at fault of the utility’s maker. When I use CDNs like this, there are <!-- WARNING … --> around the code just in case someone were to run with it, along with adding the integrity attribute.
I've also been creating HTML tools over the years when I couldn't find client-side only websites for PDF to SVG, CSV to Sheet, Audio to Video, Video to MP4.
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.
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 something similar, but with Bun + Preact, since I love that stack. I’ve found it very productive after the hurdle of the initial project setup (in which I wasted time crafting an RPC layer, etc, because I wanted to.)
> Avoid React, or anything with a build step. The problem with React is that JSX requires a build step, which makes everything massively less convenient. I prompt “no react” and skip that whole rabbit hole entirely.
I haven’t found too many issues with loading React and Babel from a CDN. I find React easier to read than straight HTML/JS. I find it more annoying to code in but seeing what state is needed in what components is a pleasant reading experience for me with single file tools.
Yep - the author is very opinionated and it's good because it works really well for his workflows/usecase.
I'm with you though, personally react is a acceleration mechanism for me because I often find existing well built components already. I don't built the same thing as the author though.
I tend to make them as Python servers which serve plain html/js/css with web components. I know this is a bit more complicated than just having a single html file with inline js and css, but the tools I made were a bit too complicated for the LLMs to get just right, and separating out the logic into separate js files as web components made it easy for me to fix the logic myself. I also deliberately prompted the LLMs to avoid React because adding I didn't want to need a build step.
The only one I actually still use is the TODO app I made:
https://github.com/cooljoseph1/todo-app
It stores everything in a JSON file, and you can have multiple TODO lists at once by specifying that JSON file when you launch it.
Indeed, likely a useful lens on the current moment I’d say.
For better/worse, and whether completely so or not, the time of the professional keyboard-driven mechanical logic problem solver may simply have just come and gone in ~4 generations (70 years?).
By 2050 it may be more or less as niche as it was in 1950??
Personally, I find the relative lack of awareness and attention on the human aspect of it all a bit disappointing. Being caught in the tides of history is a thing, and can be a tough experience, worthy of discourse. And causing and even forcing these tides isn’t necessarily a desirable thing, maybe?
Beyond that, mapping out the different spaces that are brought to light with such movements (eg, the various sets of values that may drive one and the various ways that may be applied to different realities) would also certainly be valuable.
Building little toy projects like some of these is one of my favorite ways to learn and play. Sometimes the value isn't in the initial finished product but in the concepts it exposed and knowledge or inspiration gained from that.
I guess if what you really want is only the finished product and nothing else, churning it out as quickly as possible with AI and not caring about the implementation could work for you. But it would take the fun out of it for me.
Sadly my career may eventually head in that direction. At least I'll always have a hobby to enjoy.
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.
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.
It still works (minor misalignments though), all HTML is pure (no class=, no css=, no <div>). The global CSS does everything: the forms, the drop-down menus, etc.
Nowadays, we can do even better, no build step or anything like that.
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:
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'm only at 53 tools at the moment."
Sorry if this sounds overly critical, but what do you mean "only at 53 tools?" Was there a memo I missed about a competition to host LLM-built tools?
Maybe you’re ignoring the context that he’s replying to the author and saying “only” because he’s comparing his 53 with the author’s 150+
I read the article, and I saw Simon's note about the 150+ HTML apps, I just don't get it.
There’s nothing to really get. There’s no deep meaning to the numbers or the comparison
These are great. Something you might find interesting is that you can expose a google sheet to have an interactive database. I have a map similar to yours, but with surf spots. Maybe defeats the point, but I find it handy
Edit: come to think of it, I should revisit it now that everyone can vibe code. The sheet was to allow people to add to it, now maybe easier for me to take a message and ask an agent to update the html directly
Awesome.
Couple of unsolicited comments: first is that on mobile, the featured badge sits on top of the right facing arrow. Second is that the bubble level seems to be upside down? The bubble sinks rather than floats at least on my pixel
Thanks for showing this! It’s cool, and I enjoyed reading through some of the code. Note that I tried to use some of the regex tools that needed LLMs and got a rate limit error.
I was also heavy on these single-file HTML tools. My problem was not being able to sync the localstorage data between PC and smartphone. I made a paid service which did that automatically. It didn't take off unfortunately, and I am keeping it on maintenance mode because it has some amount of free users that rely on it.
For anyone interested, to achieve synchronization I basically just use the https://github.com/google/diff-match-patch lib and save the patches in a db for each version with a version id. Then there's a generic JS file that I inject to uploaded HTML files that monkey patches the localstorage methods and optimistically updates the localstorage at the same time sending the diff to the server to save to the db.
I wonder if you can hack a LocalStorage sync feature via ATProto PDS, since you can put arbitrary JSON records via /xrpc/com.atproto.repo.putRecord and not just Bluesky posts.
The only drawback I can think of is that all of your commits are broadcast on a megaphone to the network firehose, but encryption can alleviate that somewhat.
I am not familiar with it, but I was thinking about making an open source version of this, but using webRTC, to just directly allow peer-to-peer synchronization without a centralized server.
In this type of scenario there are a lot considerations to be made though, specifically since you can't use CRDT's to handle concurrent updates on the data you have to either 1) not allow offline use of the apps, 2) create a merge conflict resolving interface or 3) just overwrite all changes with the latest one.
Idk if people would be interested in this and I haven't been using my HTML tools for a while now, so it's just an idea, maybe someone else wants to work on.
> My problem was not being able to sync the localstorage data between PC and smartphone
That's what remoteStorage is for.
<https://remotestorage.org/>
I can't get that page to respond. Did you mean <https://remotestorage.io/>?
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.
I'm a big fan of using this kind of thing at work. Rather than setting up a web server or packaging something into an installer, I just pop the bundled HTML file on a shared drive.
The CDN approach works, but I don't love depending on some third-party service just so your app continues working. Instead, I like using vite with vite-plugin-singlefile. This lets you package your JS and CSS into a single HTML: https://www.npmjs.com/package/vite-plugin-singlefile
How does the camera mode work? I tried it and it jumps wildly between 60 and 100 oO
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.
> 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.
I can only speak for myself and my not-quite two decades of professional experience, but yes pretty much!
It’s neat to see that sped up for others though with lower stakes, though it’s not quite the same unless you prompt your agent to question you back a lot (Claude is much better at this in my experience)
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.
I see, thank you.
Until vibe coding came along, the ergonomics of a library were no less important than its functionality. But I understand how LLM assisted coding changes that perspective.
I'll go tend to my empty lawn now.
You can use react with jsx without any build step in single html file as well.
Yeah I used it for this one via Babel from a CDN but it felt pretty crufty: https://tools.simonwillison.net/box-shadow
Yes, I guess it would start showing advantage for complex ones.
The idea is interesting, shame there is nothing for full stack like this, something like opinionated fossil-scm setup - which already has project management built in (for llm to use for its dev progress); together with backend and runtime state squashed inside single sqlite so you can create/delete them independently without a fuss.
One thing I tend to do myself is use https://generator.jspm.io/ to produce an import map once for all base dependencies I need (there's also a CLI), then I can easily copy/paste this template and get a self-contained single-file app that still supports JSX, React, and everything else. Some people may think it's overkill, but for me it's much more productive than document.getElementById("...") everywhere.
I don't have a lot of public examples of this, but here's a larger project where I used this strategy for a relatively large app that has TypeScript annotations for easy VSCode use, Tailwind for design, and it even loads in huge libraries like the Monaco code editor etc, and it all just works quite well 100% statically:
HTML file: https://github.com/blixt/go-gittyup/blob/main/static/index.h...
Main entrypoint file: https://github.com/blixt/go-gittyup/blob/main/static/main.js
I wondered how you got JSX but it seems you don't quite and the true magic here is the htm library.
Makes me wish there was a cross-platform equivalent to HTML Applications [1]. They were hell to develop at the time, but being able to create single-text-file tools with a browser UI, file system and network access, and app automation via COM was amazing
[1] https://en.wikipedia.org/wiki/HTML_Application
That would be neat. So instead of having to write a whole Electron or Tauri app and package it, you just target some shell program.
You could definitely build such a shell with Electron or Tauri, it punches a big hole in their security model, but you could do it.
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/
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!
[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.
A lot of investment at some very large companies you know are trying to achieve this right now, and betting big on it. So far the lack of determinism when it is required gets in the way, but we’ll see: it feels surmountable.
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.
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...
I made a heart monitor for very high heart rate https://github.com/SMUsamaShah/heart-rate which can be installed on phone as a PWA too. It could use some more polish, more features which I could do with an LLM again.
LLMs are generating app for an idea that can fit in few hundred lines of html/js. Had an idea that what if brushes were dithered in a painting tool and made a dithered painting tool. https://github.com/SMUsamaShah/dither-painter
These tools and code are ephemeral though. You don't need to use mine for example. Just ask the LLM of the time to implement the idea and in most cases it will work fine.
I've found a lot of success building in Alpine.js but I'm surprised that most people don't do this / don't like it. It makes managing reactivity a bit easier than full vanilla JS
I also started building similar tools in early 2025 and have built around 80 of them so far: https://tools.o14.ai/. Recently, I built a data viewer app (https://tools.o14.ai/excel-qa-review.html) where I can upload an Excel or CSV file containing chat queries and answers for quick manual review.
Reviewing data in Excel is painful, especially when answers are in HTML or Markdown, because you don’t get proper rendering. Building small, custom tools that reduce the friction of reviewing data makes life much easier and more pleasant. These days, I use Claude Code for Web to build most of these apps, and they are deployed on Vercel.
I love this idea! I've also been using LLMs to build tiny utilities and automations for myself, but instead of using HTML, I'm building them as:
- Shell scripts, AppleScripts, etc. that I trigger from Alfred
- Obsidian plugins
- The occasional Emacs Lisp function
They serve a similar purpose for me as OP's HTML Tools, in the sense that they let me automate a small part of my workflow that I wouldn't otherwise have automated. If I have to choose between writing AppleScript and just doing something manually, I'll pick doing something manually 100% of the time. But if I can just ask an LLM to write the automation for me and then test it in a bunch of different scenarios, the choice becomes much easier.
After reading this post, I really want to try moving some of my automations to the web. Using HTML/JS/CSS for some of these tools will let me solve a whole different set of problems. E.g. I could more easily build automations for the non-techy folks in my family instead of just keeping them to myself.
I used to dislike AppleScript but now I enjoy using it. The turning point for me was when I finally bit the bullet and read a book on the subject.
AppleScript’s human readable language lulls you in this false sense of security that you can wing it and everything will just work out. This is simply not the case, it is a very quirky language and it helps to read a book to get the right mental model.
The second thing that helped was getting AppleScript debugger from Late Night Software. They recently decided to no longer develop it and release it for free on their site. It’s worth getting if you haven’t done so already.
I've written a bunch of shell scripts like this too, but I've been focusing increasingly on web tech mainly because that way the same tools work on both my laptop and my phone.
The barcode font trick from valbaca is brilliant. I've done similar things with base64-encoded data URIs to make tools completely standalone - no network calls, no CDN dependencies.
One pattern I've settled into: keeping tools under ~200 lines of JS total. Past that threshold I start losing the ability to hold the whole thing in my head, and the main benefit of these tools is that you can open them in a text editor and understand everything immediately.
The CORS limitation that xnx mentions is real though. I've worked around it a few times by having tools accept paste-from-clipboard instead of fetching URLs directly. Less elegant but it keeps the tool self-contained and avoids the proxy problem simonw mentioned.
I've been building these for years. I think its a great entrypoint for new developers and can be incredibly useful at work for solving short term inconveniences or scripts that help automate some tasks.
I have a Vue3 started template I host at https://http://vue-template.spaghet.me/ and all I have to do is curl and I'm ready to go.
Showcase:
https://timer.spaghet.me/ https://colors.spaghet.me/ https://box.spaghet.me/ https://talk.spaghet.me/ https://farming.ope.cool https://stitch.ope.cool https://draw.ope.cool https://walz.ope.cool
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-pngNice, I'm proud I managed to nerd-snipe you :-) Thanks for taking the time.
Seriously, though, I think this solves a nicely framed simpler problem. I was thinking about a more general tool, but that's genuinely hard (you'll need heavy CV algorithms or a special ML model to detect what is background what what isn't).
To be honest, what you built here is probably sufficient anyway, because the models are better at obeying "create a white background" or "create a 0xffffff background" than "transparent", so this tool can post-process to what's needed.
When asked for "transparent", I've had a model generate a fake checkerboard pattern of gray colors to imitate how viewers render transparent areas :-) For this kind of nonsense, the transparent-png tool wouldn't do!
The best thing to say to an image model IME is "use a colour/chroma key background" and then it gives you green or blue or whatever depending on colours used in the image.
Dude, you are amazing. Maybe you should make a suggestion box. Then while you are sleeping, the AI could evaluate the suggestions, and if they are good, it could prototype the tool, and then you could review the prototypes in your waking hours before clicking the tool to production. :)
(I’m not actually kidding)
I've been calling these Single-File Web Apps. I've written a couple myself:
≈ https://fuzzygraph.com ≈ https://hypervault.github.io/
Slight correction: I'd only refer to it as a "Single-File Web App" if it has no external dependencies (where as the "HTML Tool" definition allows for external dependencies loaded from CDNs).
I wouldn't call either of these tools that either. Using View Source reveals that there's a pretty obvious build step and confronts you with massive minified blobs. There's no way a person is going to be able open that HTML as a "single file" in their text editor to pick up development where it was left off. (In that regard, the HTML tools in the linked post are closer to the definition, even when they're written to load a module from a CDN.)
Next evolution: UX should allow end users to build the prompt, and then the tool is generated and deployed at a random URL. Tool also keeps original prompt, so any user can customize into a new (random URL) tool page.
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!
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.
Surprised AI studio isn’t recommended here - you can go from prompt->preview->deploy in like a couple seconds.
They have a library of sample apps you can edit but I wish they included the prompts and history to build each since I generally can’t get large apps to work - after a while the I’ll just produces more bugs as complexity grows. But I’m also a bad vibe coder and never read the code so entirely my fault :)
I don't trust it to give me share URLs that anyone can access without a Google account and that will work forever into the future.
It may well do that, but it's not earned my trust yet!
Ah I’ve only used that feature once actually I’ll have to try it, I was talking about the deploy on gcp button (but pointlessly not free compared to your github pages recco!)
I was displeased as well with the share url requiring login for AI studio.
> "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.
> 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.
> small experimental utilities
This is what CDNs should be used for at this time—or for fetching the scripts to vendor. That’s fine, but recommending I don’t think is the best call since one folk’s experimental utility will inevitably get released into production—often not even at fault of the utility’s maker. When I use CDNs like this, there are <!-- WARNING … --> around the code just in case someone were to run with it, along with adding the integrity attribute.
Great link.
I've also been creating HTML tools over the years when I couldn't find client-side only websites for PDF to SVG, CSV to Sheet, Audio to Video, Video to MP4.
I list them at https://client-side.app/
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 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.
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 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
Nice. I do something similar, but with Bun + Preact, since I love that stack. I’ve found it very productive after the hurdle of the initial project setup (in which I wasted time crafting an RPC layer, etc, because I wanted to.)
> HTML tools may not have access to server-side databases for storage but it turns out you can store a lot of state directly in the URL.
I use indexedDB for it and will use sqlite if I start to get more serious data needs.
To make it extra useful, they should come with REST API and swagger docs on how to use the API.
This was the first submission: https://news.ycombinator.com/item?id=46236333
> Avoid React, or anything with a build step. The problem with React is that JSX requires a build step, which makes everything massively less convenient. I prompt “no react” and skip that whole rabbit hole entirely.
I haven’t found too many issues with loading React and Babel from a CDN. I find React easier to read than straight HTML/JS. I find it more annoying to code in but seeing what state is needed in what components is a pleasant reading experience for me with single file tools.
Yep - the author is very opinionated and it's good because it works really well for his workflows/usecase.
I'm with you though, personally react is a acceleration mechanism for me because I often find existing well built components already. I don't built the same thing as the author though.
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...
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
I've done something similar for a couple tools.
I tend to make them as Python servers which serve plain html/js/css with web components. I know this is a bit more complicated than just having a single html file with inline js and css, but the tools I made were a bit too complicated for the LLMs to get just right, and separating out the logic into separate js files as web components made it easy for me to fix the logic myself. I also deliberately prompted the LLMs to avoid React because adding I didn't want to need a build step.
The only one I actually still use is the TODO app I made: https://github.com/cooljoseph1/todo-app It stores everything in a JSON file, and you can have multiple TODO lists at once by specifying that JSON file when you launch it.
Endlessly churning out tools with vibe coding sounds quite boring to me. The world went and changed I guess.
Indeed, likely a useful lens on the current moment I’d say.
For better/worse, and whether completely so or not, the time of the professional keyboard-driven mechanical logic problem solver may simply have just come and gone in ~4 generations (70 years?).
By 2050 it may be more or less as niche as it was in 1950??
Personally, I find the relative lack of awareness and attention on the human aspect of it all a bit disappointing. Being caught in the tides of history is a thing, and can be a tough experience, worthy of discourse. And causing and even forcing these tides isn’t necessarily a desirable thing, maybe?
Beyond that, mapping out the different spaces that are brought to light with such movements (eg, the various sets of values that may drive one and the various ways that may be applied to different realities) would also certainly be valuable.
But alas, “productivity” rules I guess.
Building little toy projects like some of these is one of my favorite ways to learn and play. Sometimes the value isn't in the initial finished product but in the concepts it exposed and knowledge or inspiration gained from that.
I guess if what you really want is only the finished product and nothing else, churning it out as quickly as possible with AI and not caring about the implementation could work for you. But it would take the fun out of it for me.
Sadly my career may eventually head in that direction. At least I'll always have a hobby to enjoy.
> Building little toy projects like some of these is one of my favorite ways to learn and play.
Same here! That's why I'm having so much fun building nearly 100 of them in a year.
The difference here is that I didn't have to type out all of the code by hand.
Awesome. This is the way.
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.
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.
Definitely!
Not only for the user, but it makes sense for the process of making the tools as well.
If I left the agent for itself, it often come up with outrageous styles and I need to prompt it for something more sober.
---
You can do a lot with just CSS. I restored this 2009 project of mine just now:
https://alganet.github.io/ghiaweb/
It still works (minor misalignments though), all HTML is pure (no class=, no css=, no <div>). The global CSS does everything: the forms, the drop-down menus, etc.
Nowadays, we can do even better, no build step or anything like that.
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
This does bluetooth? wow.
It's so sad that there's no wysiwyg editor besides seamonkey which is truly opensource and no electron stuff.. sigh :(
also sad, that XHTML was abandoned.