The Tools That Travel

The best tools are the ones that still work when you need them again.

Simon Willison has built over 150 HTML tools—single-file applications combining HTML, JavaScript, and CSS. Each one solves a specific problem: converting JSON to YAML, cropping images for social media, extracting text from PDFs, displaying Bluesky threads. Most were prototyped with LLMs in minutes. All of them work without installation, deployment infrastructure, or ongoing maintenance.

The pattern he's documented isn't about technology preference. It's about designing tools that travel—that work today, tomorrow, and six months from now when you've forgotten how you built them.

The Architecture of Reusability

Willison's pattern starts with a constraint: everything in one file. HTML, CSS, and JavaScript inline. No build step. No bundler. No framework requiring compilation.

This isn't anti-framework ideology. It's architectural choice for a specific class of problem. If your tool has simple state, processes data client-side, and doesn't need server coordination—removing the build step removes a dependency. Fewer dependencies means fewer things that can break.

The rest of the patterns follow from this principle:

Load from CDNs, not npm. Libraries like Pyodide or Tesseract.js load directly from cdnjs or jsdelivr. No package manager, no version lockfile, no node_modules directory. The tool works anywhere you can open an HTML file.

Store state in URLs or localStorage. Encode configuration in URL parameters for instant sharing. Use localStorage for API keys or larger datasets. No database. No backend. The persistence layer is the browser.

Use CORS-enabled APIs. Willison maintains a collection of services with generous CORS policies: GitHub, PyPI, iNaturalist, Bluesky, Mastodon. If the API allows cross-origin requests, your tool can talk to it directly. No proxy server, no API wrapper.

Accept input via clipboard or file picker. JavaScript can read clipboard contents and local files without uploading anywhere. Tools like hacker-news-thread-export and ocr demonstrate this—paste data in, get results out. No server involved.

Generate files for download. Libraries from CDNs can produce PNGs, JPEGs, cropped images, even charts using Pandas and matplotlib via Pyodide. The tool creates the file in-browser and offers it for download. No backend processing.

Each pattern removes infrastructure. Not because infrastructure is bad—but because for this class of tool, removing it increases durability.

What "This Class of Tool" Means

The pattern has boundaries. It works for:

• Simple state: URL parameters or localStorage cover it
• Client-side processing: Data transforms, rendering, OCR, chart generation
• Known inputs: Files, clipboard, text, CORS-accessible APIs
• Self-contained workflows: Start to finish in the browser

It doesn't work when you need:

• Complex state coordination: Multi-user collaboration, real-time sync
• Server-side compute: Heavy processing, private data, rate-limited APIs
• Progressive enhancement: Tools for users without JavaScript
• Component composition: Large applications with shared UI patterns

The skill isn't knowing the patterns. It's recognizing when they fit.

Build Once, Use Forever

The clipboard-viewer tool Willison built in 2022 still works today, unchanged. It will work in 2027. That's not a feature of simplicity—it's designing for durability. The architecture doesn't age because there's nothing to age.

The Practice

If you're building a tool, ask: Does this need to travel?

If it's a one-time prototype, use whatever's fastest. If it's infrastructure for a team, use what scales. But if it's a tool you'll want again in six months—or that someone else might want to use, modify, or learn from—the single-file pattern gives you something valuable: tools that work today and tomorrow without thinking about them in between.

You can explore Willison's collection at tools.simonwillison.net. Almost all include "view source" links to GitHub, where commits contain the prompts or transcripts used to build them. The tools are their own documentation.

Build it once. It'll still work tomorrow.