When I started building SegaFlash, I made one architectural decision that shaped everything: if a file can be processed in the browser, it never touches a server.
No upload queues. No "your file will be deleted in 24 hours" promises you have to trust. No storage costs. Here is what that looks like in practice, and what I learned shipping 50+ tools this way.
The stack is boring — on purpose
Almost everything is vanilla JavaScript plus a few well-chosen libraries:
- Canvas API for image compression, resizing, watermarking and format conversion
- pdf-lib / PDF.js for merging, splitting and editing PDFs entirely in memory
- Tesseract.js for OCR that runs on the user's own CPU
- ONNX Runtime Web for AI tasks like background removal — the model downloads once (~40 MB) and then inference is 100% local
Lesson 1: File size is a UX problem, not a storage problem
The background remover taught me this. Users would upload a 45 MP phone photo and the model would choke. The fix was simple: downscale to a max of 1024px on the longest edge before inference. Quality stayed great for the output people actually need, and processing time dropped by ~5x.
The same trick powers the image compressor — draw to canvas at the target dimensions, export at a quality ladder (try 0.85, step down until the size target is met), done.
Lesson 2: WordPress will mangle your JavaScript
Most of the tools live inside WordPress posts, and wpautop loves injecting <p> and <br> tags into inline scripts — which silently kills them with syntax errors. Six of my tools were dead for exactly this reason (plus a regex-escaping bug and one missing brace).
The durable fix was a single render-time snippet that protects tool scripts from wpautop mangling, instead of editing 51 posts one by one. If you ship JS inside CMS content, sanitize at render time, not at authoring time.
Lesson 3: "Runs locally" is a feature users understand
I expected people to care about speed. They care about privacy more. "Your files never leave your device" is the single line that converts visitors — for the PDF to Word converter, the password generator, everything.
The trade-offs are real
Client-side isn't free:
- Big WASM models mean a heavy first load (mitigate: lazy-load the model only when the tool is opened, and show honest progress)
- Low-end phones struggle with OCR and AI inference
- You can't do anything that genuinely needs a server (real-time collab, huge files)
But for the classic "utility tool" category — compress, convert, generate, calculate — the browser is enough, and the user wins on privacy, speed and cost.
Try them
All 50+ tools are free with no sign-up on the SegaFlash tools hub. The calculators (like the mortgage calculator and BMI calculator) are pure JS too — view source and steal whatever is useful.
If you are building client-side tools, I would love to hear how you handle the model-size problem. Drop your approach in the comments.
Top comments (0)