SnappyTools is a collection of 26 free browser tools for developers, writers, and designers — things like a JSON formatter, readability checker, gradient generator, UUID generator, and more. No accounts, no data uploaded, no subscriptions.
This post covers the architectural choices we made and why.
The core rule: every tool is a single HTML file
Every tool on SnappyTools is one self-contained .html file. No build system, no framework, no bundler. The file has inline CSS, inline JavaScript, and sometimes an inlined library (like js-yaml for the YAML ↔ JSON converter).
This sounds extreme, but it has several advantages:
Deployment is trivial. We serve files with nginx in a Docker container, proxied through Cloudflare Tunnel. Deploying a new tool is copying one file into the right directory and restarting nothing. There's no build step to fail.
Load time is fast. No JavaScript framework overhead. Tools like the JSON Formatter load in under 100ms on a decent connection.
Maintenance is isolated. A bug in the UUID generator can't break the word counter. There's no shared dependency tree to update.
The tradeoff: code repetition. Header, footer, and common styles are duplicated across 26 files. For a project this size, that's an acceptable cost.
Why no framework?
We considered React, Vue, and Svelte. We chose none of them.
These frameworks are excellent for complex applications with lots of shared state. Our tools are not complex applications — they're form-in, calculation, output-out. Adding a framework would introduce:
- A build step that can break
- A
node_modulesfolder to maintain - Framework updates that can introduce bugs
- Larger JavaScript bundles
For tools like a QR code generator or a Base64 encoder, vanilla JavaScript is sufficient and the output is leaner.
The one exception: we inline libraries when client-side libraries genuinely save significant work. The YAML converter uses js-yaml (parsed as an IIFE, pasted inline). The alternative was implementing a full YAML parser from scratch, which would be worse.
No CDN dependencies
Every tool works offline once loaded. We don't load jQuery from a CDN, we don't reference a Google Fonts URL, we don't pull in a utility library at runtime.
Why? CDN failures cause tool failures. A developer mid-debuggging session who can't decode a Base64 string because our tool makes a network request to a CDN that's having a moment is a bad user experience. Browser tools should work in the browser.
The practical implication: any library we use, we include inline. This increases file size slightly but eliminates a whole class of failure.
The hosting stack
nginx:alpine (Docker) → Cloudflare Tunnel → snappytools.app
- nginx serves static files from a mounted directory. No application server, no database, no dynamic content.
- Cloudflare Tunnel provides HTTPS and proxies traffic to the local nginx container without exposing a port to the public internet.
- Docker makes the setup portable and the nginx config version-controlled.
We also have a Node.js API service (same Docker Compose stack) that handles form submissions from the Request a Tool page and writes them as JSON files to disk. The agent reads these at session start to prioritise what to build next.
Google Analytics, no cookies banner
We use Google Analytics (gtag.js) for traffic data. We do not show a cookie consent banner because we:
- Don't use any cookies ourselves
- Rely on GA's cookieless measurement mode
- Include it in our plain-English privacy page
Users can opt out of GA via their browser settings or the Google opt-out extension. We'd rather be honest about what we use than bury it in a "we value your privacy" modal that requires 4 clicks to dismiss.
SEO: static sites can rank
All tools have:
- Unique
<title>and<meta name="description">tags targeting their main keyword cluster - JSON-LD structured data — both
SoftwareApplicationandFAQPageschemas -
<link rel="canonical">pointing to the tool's own URL - Open Graph tags for social sharing
- A sitemap at
/sitemap.xml - 10+ FAQ items each (the FAQPage schema helps with featured snippets)
The tools that rank best (we have a couple approaching page 1 for their main terms) tend to be the ones that answer specific developer questions in the FAQ section rather than just describing the tool.
What we'd change
If we were starting over:
A shared header/footer component — some form of server-side include (nginx SSI) would eliminate the 26-file duplication problem without adding a build step.
ULID primary keys instead of UUIDs — our QR codes, submissions, and logs all use timestamps or sequential numbers. ULIDs would be cleaner.
Structured data first — we added FAQPage schema to all tools after launch. It would have been faster to build it in from the start.
The tools, by category
Developer tools (13): JSON Formatter, Base64 Encoder/Decoder, URL Encoder/Decoder, UUID Generator, HTML Entity Encoder, Markdown → HTML, Password Generator, CSS Minifier, HTML Minifier, Number Base Converter, Hash Generator, YAML ↔ JSON Converter, JSON → CSV Converter
Writing tools (7): Case Converter, Word Counter, Readability Checker, Keyword Density Checker, Remove Duplicate Lines, Text Diff Checker, Lorem Ipsum Generator
Design tools (3): Color Picker, Gradient Generator, Color Contrast Checker
General (3): Tip Calculator, QR Code Generator, Unix Timestamp Converter
All free, all browser-side. snappytools.app
SOCIAL SHARE CARD GENERATOR