Most "free online tools" follow the same pattern: upload your file to a server, process it with a backend script, and send the result back. It works, but it creates a privacy problem. Every file you process passes through someone else's infrastructure.

I wanted to prove there was a better way. Over 77 days, I built ToolKnit — a suite of 72 free online tools where zero files leave the user's device. No backend processing. No server uploads. Everything runs in the browser.

Here is how I did it, what I learned, and where I failed.

The Core Architecture

ToolKnit is a static site. No Node.js server, no Django app, no serverless functions. Just HTML, Tailwind CSS, and vanilla JavaScript sitting behind Nginx on a $5/month VPS. The only server-side code is a single PHP script (track.php) that records anonymous page-load counts — no file processing, no user data.

Every tool is a self-contained HTML page with its own JavaScript file. When you visit compress-pdf.html, the entire PDF compression pipeline runs in your browser using:

• PDF-lib.js for PDF manipulation (compression, merging, splitting)
• Canvas API for image processing (crop, resize, convert)
• FFmpeg.wasm for video and audio conversion (compiled from C to WebAssembly)
• Web Audio API for audio analysis (BPM detection, waveform visualization)
• File System Access API for reading and writing local files

The user picks a file, the browser processes it locally, and the result is downloaded directly from memory. The file never touches a server.

WebAssembly: The Enabler

The biggest technical enabler was WebAssembly. Tools like video-to-audio conversion, audio trimming, and video-to-GIF would be impossible in a browser without it. I use FFmpeg.wasm (the WebAssembly port of FFmpeg) for all media conversion tasks.

The trade-off is size. FFmpeg.wasm adds roughly 25MB to the initial load. To mitigate this, I load it lazily — only when the user actually selects a media file. The core tool page loads instantly with a lightweight UI, and the WebAssembly module downloads in the background while the user is choosing their file.

SharedArrayBuffer is required for multi-threaded FFmpeg.wasm, which means every media tool page needs Cross-Origin Isolation headers (COOP and COEP). I handle this with a service worker (coi-serviceworker.js) that injects the required headers on the fly, so I do not need to configure Nginx for each tool individually.

The Service Worker Strategy

ToolKnit is a Progressive Web App with an aggressive caching strategy. The service worker (service-worker.js) precaches all tool pages, JavaScript files, and blog articles on install. This means:

1. Offline access — All tools work without an internet connection after the first visit
2. Instant loading — Subsequent visits load from cache, with background updates
3. Version management — Every deploy increments the cache version (currently toolknit-v67)

The challenge is cache invalidation. Every time I add a tool or fix a bug, I need to bump the cache version and update the PRECACHE_URLS array. Early on, I forgot to bump the version after a deploy and users were stuck with a stale version for days. Now it is part of my deployment checklist — no exceptions.

The Deployment Disaster That Changed Everything

On May 27, I made a deployment mistake that nearly destroyed the site.

I was using SCP to upload multiple files at once. Two files had the same basename but different paths: blog/index.html and the root index.html. When I ran:

scp blog/index.html tools/video-screenshot.html root@server:/www/wwwroot/toolknit.com/

The blog index.html overwrote the homepage. The blog video-screenshot.html overwrote the tool page. The entire homepage was replaced with a blog article list. The video screenshot tool was replaced with an SEO blog post.

I restored from backup within minutes, but the lesson was seared into my brain. From that day forward, my deployment rule is absolute:

One file per SCP command. Always specify the full target path. Never upload multiple files to the same directory in one command.

It is slower. It is tedious. It has prevented every deployment accident since.

The Architecture Refactor That Saved My Sanity

By June 1, I had 70 tool pages, each with an inline JavaScript array listing related tools:

var tools = [
  {n:"Compress PDF",u:"compress-pdf.html"},
  {n:"Merge PDF",u:"merge-pdf.html"},
  // ... 70 entries
];

Every time I added a new tool, I had to update this array in all 70 HTML files. That is 70 file edits per tool launch. I was spending more time updating related-tool lists than building actual tools.

So I stopped shipping features for a day and rebuilt the entire system:

1. Created assets/data/tools.json — a single source of truth for all tools
2. Created assets/js/related-tools.js — fetches the JSON and renders related tools dynamically
3. Removed all inline var tools=[...] arrays from 70 HTML files

Now, adding a new tool means adding one entry to tools.json. Every tool page automatically shows the updated related tools list. It was the most boring deploy I have ever made — and the most impactful.

Privacy Hardening: The Day I Scrubbed My Own Analytics

On May 26, I realized my anonymous analytics system had a flaw. The track.php script was storing raw IP addresses in daily JSON files on the server. The data was never shared, never sold, and never connected to any user identity. But it felt wrong. If I am going to claim that ToolKnit respects privacy, the analytics system should reflect that.

I spent the entire day on three changes:

1. Rewrote track.php to hash all IPs and visitor IDs with day-scoped SHA-256 before storage. The hash changes every day, so you cannot track a single IP across days.
2. Scrubbed historical data — batch-migrated all existing daily JSON files, converting 650 raw IPv4 addresses, 181 IPv6 addresses, and 763 raw UIDs into hashed values.
3. Saved a backup first — analytics-backup-20260526-status-scrub.tgz on the server, just in case.

No user will ever notice this change. The analytics dashboard looks identical. But I sleep better knowing there are no raw IPs sitting on my server.

Internationalization: Chinese Without a Framework

ToolKnit supports English and Chinese. I did not use i18next or any localization framework — just a simple JSON file (locales/zh.json) with translations for all tool titles and descriptions, and a lightweight i18n.js that swaps text content based on the user's language preference.

The tricky part is cache busting. When I add a new tool and its Chinese translation, I need to bump the zh.json cache version in i18n.js so the browser fetches the updated translations. Forget to bump, and Chinese users see the old tool list. I have forgotten exactly twice. Both times, I received confused emails within hours.

FIGlet Fonts and CORS: A Cautionary Tale

The most recent technical challenge was the ASCII Text Banner tool. I initially used the figlet.js library with fonts loaded from a CDN (unpkg.com). It worked perfectly in development. Then I deployed it, and every font request was blocked by CORS policy.

The fix was to download all 20 FIGlet font files (.flf) and host them locally under /assets/fonts/. Simple in hindsight, but it took me an hour of debugging to realize that unpkg.com does not set Access-Control-Allow-Origin headers for .flf files.

Lesson: always test CDN resources against CORS before deploying. Browser development servers often skip CORS checks, so everything works locally and breaks in production.

The Tech Stack Summary

What I Would Do Differently

1. Start with a build system. I went full vanilla JS because it was fast to start. Now, with 72 tool pages and 70+ JavaScript files, I miss tree-shaking, bundling, and TypeScript type checking. A lightweight Vite setup would have saved me from several runtime bugs.

2. Automate deployments earlier. I deploy by running SCP commands one at a time. A CI/CD pipeline (even a simple GitHub Actions workflow) would eliminate the risk of manual deployment errors.

3. Test CORS from day one. The figlet.js CORS issue was entirely preventable. I should have tested all external resource loads against production CORS headers before deploying.

4. Hash analytics from day one. Storing raw IPs was unnecessary and created a privacy debt that took a full day to clean up. The hashed version works identically and is strictly better.

Alternatives and Related Projects

If you are interested in browser-based tool suites, here are some projects worth exploring:

Smallpdf

Polished PDF tool suite with a clean API. Great if you need server-side PDF processing or want to integrate PDF features into your own app. Their free tier is limited to 2 tasks/day.

Squoosh

Google's browser-only image compression tool. It uses WebAssembly codecs (MozJPEG, WebP, AVIF) and proves that client-side image processing can match server-side quality. A great technical reference if you are building your own image tools.

TinyWow

A broad free tool suite similar to ToolKnit in philosophy. Good for comparing approaches to the same problem — they use server-side processing while ToolKnit uses browser-only processing.

Building ToolKnit has been the most intense learning experience of my development career. Not because the technology is cutting-edge — it is not. But because the constraint of "everything must run in the browser with zero server processing" forces creative solutions that you would never discover otherwise.

If you are building something similar, or if you just want to compress a PDF without uploading it to a stranger's server, visit toolknit.com. No signup. No upload. No catch.

Written by Zihang Dong, solo developer of ToolKnit. 72 tools, 77 days, zero backend processing. Content published under CC BY-SA 4.0.