Every "free online tool" site has the same shape: pick a task — resize an image, merge a PDF, decode a JWT — upload a file, wait, download the result. That upload almost never needs to happen. Browsers have had the APIs to do this work locally for years. The upload step exists because it's the easiest way to build the product, not because the task requires a server.
That's the premise behind Tabreon: 30 tools across text, developer, QR, image, and PDF categories, all running as client-side JavaScript in the tab. No install, no account, and — for 28 of the 30 — no file ever leaves your browser.
The rule: browser-first by default
Early in the project this became an actual architectural constraint, not just a pitch. Every new tool has to justify why it can't run client-side before it's allowed to touch a server. In this codebase that's written down as an ADR (architecture decision record), and it's held for the vast majority of the catalog:
- Text tools (word/character/line counters, case conversion, diff checking) — pure string manipulation, trivially client-side.
- Developer tools (JSON formatting, Base64, JWT decoding, hashing, regex testing) — the Web Crypto API and standard JS cover almost all of it.
- PDF tools (merge, split, rotate, watermark, page extraction) — pdf-lib and pdfjs-dist run fine in a browser tab.
- QR generation — qr-code-styling, dynamically imported so it doesn't bloat the initial bundle.
- Most image tools (resize, compress, format conversion between JPEG/PNG/WebP/AVIF, crop) — Canvas and the various browser image codecs handle this.
The engine logic for all of this lives in its own layer (lib/engines/), separate from the UI components. That split isn't just tidiness — it means the actual transform (the JSON parser, the hash function, the PDF page manipulation) is unit-testable without touching React at all.
Where the rule breaks
Two tools don't fit: HEIC conversion (the format iPhones save photos in) and SVG-to-PNG rasterization. Browsers don't ship a general HEIC decoder — Apple's format is patent-encumbered in a way that's kept it out of the standard web codec set — and reliable SVG rasterization at scale has its own edge cases (external references, script content, malformed markup) that are safer to handle in a controlled server environment than to trust to a canvas element across every browser.
Rather than fake a client-side implementation or quietly bolt on a server endpoint and call the whole platform "private" anyway, this became an explicit, narrow exception to the same ADR: a tool can go server-side only if there's genuinely no practical browser path, and even then:
- The endpoint is rate-limited per visitor.
- The file is used only to produce the converted output.
- Nothing is logged or retained after the response is sent.
- The exception is disclosed, not hidden — it's called out in the privacy policy and now in the README, not folded into a blanket "everything's private" claim.
That distinction — disclosed exception vs. silent violation — mattered more to me than keeping a clean "100% client-side" marketing line. A privacy claim that's true for 28 out of 30 tools and honest about the other 2 is more trustworthy than one that's true for 30 out of 30 in the pitch deck and false in the network tab.
The stack, briefly
- Next.js (App Router) + TypeScript strict
- Tailwind CSS v4 for styling
- Cloudflare Workers via OpenNext for hosting — the whole app, including the two server-side conversion routes, runs on Workers rather than a traditional Node backend
- Cloudflare D1 for the small set of features that genuinely need a database — feedback, early-access signups, feature-request voting — again, disclosed as exactly what they are rather than bundled into vague "we may collect data" language
- Vitest for unit tests, Playwright for e2e — 561 unit tests at last count, covering the engine layer specifically because that's the code where a silent regression (a PDF merge that quietly drops a page, a hash function that's off by one byte) is the kind of bug that erodes trust fastest
One genuinely annoying discovery along the way: building the Workers deployment target on native Windows fails with pnpm symlink permission errors inside node_modules/.pnpm — not a code bug, a Windows/pnpm/OpenNext interaction. Building from WSL2, Linux, or CI sidesteps it entirely. Leaving that here in case it saves someone else a debugging afternoon.
What's next
The tool catalog keeps growing — a text diff checker and the two format-conversion tools above are the most recent additions. Longer-term, there's a planned URL-shortener/analytics cluster that would introduce an optional paid tier, but the browser-based catalog that exists today stays free permanently — nothing that ships free moves behind a paywall later.
If you try it and something feels rough, or a tool you reach for regularly online is missing, I'd genuinely like to hear about it.
