DEV Community: Bruce Xu

150 browser tools, no server, no uploads — the architecture behind a static toolkit

Bruce Xu — Wed, 04 Nov 2026 07:53:51 +0000

I shipped a toolkit of 150 small browser tools. Every one of them runs in the tab: the file is read locally, processed locally, and never sent to a server.

That's not a marketing line — it's an architectural constraint I imposed on myself, and it made almost every tool harder to build. Here's what it costs and how the pieces actually work.

What the 150 tools are

Roughly four groups, and each one needed a different processing model:

Text and dev utilities (the majority). JSON/YAML/XML, Base64, JWT, regex, hashes, cron parsing, SQL formatting, diff, CSV ↔ JSON. Pure JS, no wasm, instant. These are easy and they're not why anyone stays.
Image tools. Compress, resize, crop, convert, watermark, collage, OCR. Canvas + OffscreenCanvas in Web Workers, so the main thread keeps painting at 60 fps while a 12 MP photo is being re-encoded.
PDF tools. Merge, split, page ranges, watermark, PDF → images, images → PDF. pdf-lib, entirely in memory.
Audio and video. Trim, video → GIF, extract audio, screenshots, screen/camera/mic recording. ffmpeg.wasm in a worker, single-threaded — full write-up of why in a separate post.

Why static export, and why it's a feature

The whole site is a Next.js static export on Cloudflare Pages: HTML pages, no server process.

The performance reason is boring (CDN cache). The privacy reason is the real one: there is no server to send a file to. A tool can't accidentally upload your PDF if the deployment has no runtime that accepts a PDF. That's a property I can't lose by shipping a careless commit, and it's worth more than any privacy policy paragraph.

The cost is that everything client-side has to fit in a static bundle, which is where the 25 MiB per-asset limit and the wasm-from-CDN compromise come from.

The data flow, for every tool

File → <input type=file> → ArrayBuffer (in the tab)
     → wasm / worker / canvas
     → Blob → URL.createObjectURL → <a download>

There is no fifth step. If you open the Network panel and process a 40 MB video, the only requests you'll see are the page, the JS, and the wasm engine on first use. That's the whole test, and it's why I wrote a separate post on how to audit claims like this one.

Four things this architecture cost me

1. No sync, no history across devices, no cloud backup. No account means no place to put them. Some users ask for it; the honest answer is that adding it would delete the only thing that makes this different.

2. Memory ceilings are real and user-visible. A very large video can kill a tab. On phones it's worse. I try to fail with a message rather than a blank screen, and I don't always succeed.

3. The first video use is a 30 MB download. Unavoidable given the asset limit, so the UI shows a progress number instead of a spinner and explains what's downloading.

4. Bundle weight on a 150-tool site. Every tool page lazy-loads its own chunk, which mostly works, and the entry bundle is small. It's not a small site, and pretending otherwise would be silly.

What's still rough

The homepage is a wall of 150 tools. I know that's bad IA. Category pages help; the homepage still isn't good.
Mobile works for text and image tools; the video tools are desktop-first and I'd rather say so than ship a spinner.
16 languages is a maintenance tax. Every new tool is 16 translations before it's usable, and machine-translated UI copy for technical terms is a permanent quality problem.

The question I actually want answered

If you had to delete 100 of these 150, which 50 would you keep?

I'm not being cute. The long tail of "tool #151" costs me more in maintenance than it returns, and I'd rather make a handful genuinely good than keep widening a grid.

Start here if you want to try one: image compressor — no upload, no signup. Full list at wtoolskit.com. It installs as a PWA, so it also works with Wi-Fi off.

How to check whether a "client-side" web tool really stays client-side

Bruce Xu — Mon, 02 Nov 2026 09:09:50 +0000

"Processed in your browser." "Your files never leave your device." "100% client-side."

Those sentences cost nothing to write. I've audited a dozen tools that say them, and the claim is true for maybe half. The failure mode is rarely a lie — it's usually a half-truth: the preview is local, the export is uploaded; or the file is uploaded but "only for processing"; or the compression happens in the tab and then the original quietly goes to a CDN for "backup".

Here are the four checks I run, in the order that catches the most of it fastest. DevTools and about five minutes per tool.

1. Watch what leaves the tab

Open DevTools → Network, tick Disable cache, then run one real file through the tool.

Filter to Fetch/XHR and sort by Size, descending.
Look for any POST / PUT whose request body is roughly the size of your file (or the sum of several chunked requests matching it).
Also check the WS filter. An upload over a WebSocket won't show up as an XHR, and it's a common way to hide one.

A tool that processes locally will show you JS, a wasm binary, maybe fonts — and nothing carrying your file. A tool that uploads will show a request with a payload you can literally see in the Payload tab.

Two things that make this check lie to you: an upload that's split into 64 KB chunks looks small in every individual row (sum them), and an upload triggered only on download looks clean until you click export. So do the check twice — once on import, once on export.

2. Turn the network off

Not "throttle to offline" — actually turn Wi-Fi off, then reload.

Page still loads and the tool still works → the processing really is local, or at minimum the whole pipeline is cached.
Page loads from cache but the tool hangs on "processing" → the engine is remote. That's the single loudest signal you'll get.

One caveat: a PWA that cached its shell will load offline even if its engine is a server API. That's why check 2 never stands alone — it's a filter, not a verdict.

3. Count the third-party requests

This is where "local" starts needing a definition, and where most audits stop too early.

Open the Network panel on a cold load (hard reload, cache disabled) and look at the Domain column. What you'll typically find:

Request type	Does it leak the file?	Does it leak you?
Your page + JS bundle	No	IP, UA, Referer
wasm engine from a public CDN	No	IP, UA — and the CDN operator sees which tool you're using
Google Fonts / analytics	No	IP, UA, page, sometimes a client id
Ad script	No	IP, UA, plus whatever the ad network fingerprints
`POST` with your file in it	Yes	—

So: "your file never leaves your device" and "this page makes zero network requests" are different claims. A tool can honestly make the first and still phone home constantly. When a tool's privacy page conflates the two, that's not proof of bad faith, but it is a reason to run check 4.

4. Look for the machinery

If processing is local, something in the tab has to do the work. Local processing has a fingerprint:

a .wasm file (ffmpeg, sql.js, ImageMagick, OpenCV — anything heavy),
or a Web Worker (worker.js in the Network panel, or a blob: worker),
or hot canvas / OffscreenCanvas usage for image work.

If you find none of those and the only thing that happens when you hit "process" is a fetch('/api/...'), you're looking at a server. No wasm, no worker, no canvas, but a 2.4 MB → 210 KB result — that's arithmetic happening somewhere else.

The three fake-local patterns

These are the ones I keep meeting. All three can claim "client-side" without technically lying.

1. Local preview, remote export. The crop/trim UI is local (it's just CSS and a <video> element), the actual encode is an upload. Check: does the export button fire a request?

2. Local processing, remote copy. The file is compressed in the tab and also sent to storage "so you don't lose it". Check: is there a PUT to somewhere that isn't your own download?

3. Local engine, remote data. The wasm runs in the tab, but the file is passed to a third-party API for OCR / transcription / "AI enhance". Check: any POST after the wasm finishes.

The honest boundary

I'd rather state the limit of this method than oversell it.

Local processing does not mean zero network requests. The page, the JS, the wasm, the fonts, and any analytics or ad script all reveal your IP and user agent. What "local" should mean is narrower and testable: the bytes of your file are read by code running in your tab, and no request carries them anywhere. That's the claim worth checking, and all four checks above test exactly that.

If you want to verify a specific tool, the fastest route is usually its own documentation of third-party requests. A tool that lists them is telling you it expects to be checked; a tool that only says "we care about privacy" is telling you it doesn't.

Disclosure: I build one of these — a set of 117 browser tools at wtoolskit.com. Free, no account. Don't take my word for it: the four checks above are exactly how I'd audit it, and the network panel doesn't care who wrote the page.

How I Built a Suite of 100+ Dev Tools That Runs 100% in the Browser

Bruce Xu — Tue, 20 Oct 2026 17:37:26 +0000

A few months ago, I was inspecting a JWT token using a popular online utility when I noticed network requests firing off every time I pasted a string into the input box.

That moment made me uncomfortable. Why do we send sensitive environment variables, API payloads, and tokens over the wire just to run standard string manipulation or formatting?

That inspired me to build WToolsKit — a pure frontend platform providing 100+ utilities that run entirely inside the client browser.

🏗️ The Architecture: Pure Client-Side Magic

To eliminate server dependencies, cloud bills, and privacy risks, I relied heavily on modern browser Web APIs:

Client-Side Compression: Using HTML5 <canvas> and FileReader APIs to manipulate raw image data directly without sending files to an API endpoint.
Zero Network Overhead: Formatting JSON or calculating text diffs happens in memory via Web Workers/pure JS functions, making execution instantaneous.
Offline First Capability: Since there is no backend API, once the static assets load, tools function flawlessly even on slow or unreliable networks.

🚀 Key Tool Categories

Developer Tools: JSON Validator, RegEx Debugger, JWT Decoder, Base64/URL Encoding.
Design Helpers: Color Picker, CSS Shadow/Gradient Generators, SVG Cleaners.
Converters & Formatters: Text Diff, Markdown Preview, Image Format Converters.

🔗 Check It Out

You can explore the full collection of tools at https://www.wtoolskit.com/.

If you're a fellow builder, I'd love to hear your thoughts on pure browser-based web tools:

How do you handle sensitive data when debugging on web utilities?
What other browser-native APIs do you think are underutilized for dev tools?

Thanks for reading!