Backup time = (battery Ah x battery voltage x usable depth of discharge) / load in watts

A worked example: a 150Ah, 12V battery at 80 percent usable capacity gives you 1,440 watt-hours. Run a 500W load on it and you get just under 3 hours. Change the load to 200W and the same battery lasts over 7 hours. Most people get this wrong because they guess the load instead of adding it up.

Doing this by hand every time you change an appliance is tedious, so I use a free calculator that does it instantly — enter your battery size and load, and it tells you the backup time. No sign-up, no download: https://segaflash.com/2026/09/17/solarbatterybackuptimecalculator/

Two things the calculator reminds you of that the raw math hides: first, never plan to drain a lead-acid battery to zero — staying above 50 percent depth of discharge roughly doubles its life. Second, your inverter is not 100 percent efficient, so add a small margin to the load side. Plan with those two rules and your backup estimate will be honest instead of optimistic.

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.