I just wanted to compress a confidential document. Instead I built 60 client-side file tools.

Nengil — Mon, 27 Apr 2026 00:33:49 +0000

It started with a small frustration. I needed to compress a few PDFs that contained personal information — bank statements, passport scans, the kind of thing you don't want sitting on a stranger's server.

I opened the first "free PDF compressor" Google gave me. It uploaded my files. The progress bar was reassuring. The privacy policy was 8,000 words and reserved the right to "use uploaded content for service improvement."

I closed the tab. Tried another. Same pattern. Tried a third. Same.

Finally I opened a desktop tool, fought with the install, used it twice, never opened it again.

A few weeks later I was converting a video for WhatsApp, then a HEIC photo from my phone, then a CSV to JSON, then trying to extract text from a screenshot. Different sites, different uploads, different cookie banners. The friction was constant.

So I built The Local Kit — 60 file tools that run entirely in your browser. No uploads. No signup. No tracking cookies. Files never touch a server.

🔗 thelocalkit.com

This post is the technical breakdown of how that's actually possible in 2026.

The architecture decision: client-side everything

The defining choice was deciding that EVERY tool processes files locally. No "fast tier on server, slow tier on browser" hybrid. Just pure client-side.

This sounds extreme but the reasoning is simple:

The moment you have a server processing user files, your privacy policy gets longer
The moment you have a server, you have ongoing infrastructure cost
The moment you have a server, you have to scale it
The moment you have a server, your "no upload" promise is gone

Modern browsers are powerful enough that 95% of file operations work great client-side. The remaining 5% (e.g., processing a 10GB video file) — I just don't support yet. Fair tradeoff.

The stack, tool by tool

Video & audio: FFmpeg.wasm

The hardest piece. FFmpeg compiled to WebAssembly, weighing about 25MB. Loads on demand the first time someone visits a video tool.

import { FFmpeg } from '@ffmpeg/ffmpeg';

const ff = new FFmpeg();
await ff.load({
  coreURL: '/vendor/ffmpeg-core.js',
  wasmURL: '/vendor/ffmpeg-core.wasm',
});

// Compress a video
await ff.writeFile('input.mp4', new Uint8Array(await file.arrayBuffer()));
await ff.exec(['-i', 'input.mp4', '-c:v', 'libx264', '-crf', '28', 'output.mp4']);
const data = await ff.readFile('output.mp4');

Real FFmpeg, real H.264 encoding, real 10-line video compression — running on a phone CPU.

PDF: pdf-lib + pdf.js

Two libraries, different jobs:

pdf-lib — generation, modification, merging, splitting
pdf.js (Mozilla) — parsing, rendering, text extraction

import { PDFDocument } from 'pdf-lib';

const merged = await PDFDocument.create();
for (const file of files) {
  const pdf = await PDFDocument.load(await file.arrayBuffer());
  const pages = await merged.copyPages(pdf, pdf.getPageIndices());
  pages.forEach(p => merged.addPage(p));
}
const bytes = await merged.save();

PDF merge in 7 lines. No server.

AI background removal: U²-Net via @imgly/background-removal

Runs an actual neural network in the browser via ONNX runtime. The model is ~80MB, downloaded once and cached.

import { removeBackground } from '@imgly/background-removal';

const blob = await removeBackground(imageURL, {
  publicPath: '/vendor/imgly/',
  output: { format: 'image/png', quality: 0.95 },
});

3 seconds on a Macbook for a typical photo. No upload of your face/photo to any "AI service."

AI image upscaling: Real-ESRGAN (ONNX)

Real-ESRGAN was the SOTA upscaler. Compiled to ONNX, it runs via WebGL or WebGPU in the browser.

const result = await upscaleImage(imageBlob, { scale: 4 });
// 1024×1024 → 4096×4096, no server, all on your GPU

Worker isolation + SharedArrayBuffer

The big secret to not freezing the UI on heavy operations: everything heavy goes in a Web Worker, with SharedArrayBuffer for zero-copy memory sharing.

But SharedArrayBuffer requires cross-origin isolation (COEP/COOP headers). The traditional require-corp mode breaks CDN scripts. The modern fix: credentialless COEP.

# netlify.toml
[[headers]]
  for = "/*"
  [headers.values]
    Cross-Origin-Embedder-Policy = "credentialless"
    Cross-Origin-Opener-Policy = "same-origin"

This lets FFmpeg load from a CDN, while still enabling SharedArrayBuffer. Critical for video tools.

The hard parts (honest list)

Memory limits. Browser tabs have ~2-4GB heap on desktop, ~500MB-1GB on mobile. A 1.5GB video on mobile = guaranteed crash. I added differentiated file size warnings: 1GB on desktop, 500MB on mobile.

WebAssembly model downloads. AI features need to download 50-200MB once. I show progress bars and cache aggressively in the browser. After the first use, the model is instant.

Browser compat. SharedArrayBuffer needs Chrome/Edge/Firefox 119+. I detect this on page load and show a friendly upgrade message instead of a broken UI.

HEIC/HEVC. Apple formats. Mostly impossible to decode in vanilla browsers — I use a HEIC decoder in WASM as a fallback, but quality varies.

Internationalization. Site is available in 14 languages with proper hreflang. The build script (Python) pulls translations from JSON files and injects them into 60 HTML files × 14 locales = 840 generated pages. All static, no SSR.

What surprised me

The thing I didn't expect: most "online tools" don't actually need to be online.

Once you accept that the browser is the runtime, you stop needing a backend for most things. No server scaling, no privacy policy negotiating, no API keys management. You ship static HTML + JS + WASM and call it done.

The economics are wild too. The site costs ~$0/month to run (Netlify free tier handles it). The closest paid competitor charges $10/month per user for the same set of tools.

Try it / give feedback

Site: thelocalkit.com

It's free, no signup. If you find a bug or have a feature idea, the contact form on the site goes to me directly.

If you're a developer who'd want to dig into the implementation, I'm planning to open-source individual tools as standalone npm packages over the next few months.

That's the gist. Happy to answer questions about any specific tool or technical decision in the comments.

DEV Community: Nengil