Three months ago, I was laid off from my job as a senior frontend engineer.
While applying for roles and sorting out administrative paperwork, I kept hitting the same frustrating hurdle: formatting passport photos under strict 240KB limits, converting iPhone HEIC files, and compressing document scans.
Every online tool I tested felt compromised. They either:
- Forced me to upload sensitive personal documents to unknown backend servers.
- Hit me with an aggressive paywall after converting 2 or 3 files.
- Froze the browser tab with sluggish, blocking JavaScript.
Instead of burning out on endless resume submissions, I decided to build a local-first solution: IMG Free Toolkit — an image suite running 100% inside the client browser with zero server uploads.
Here is a breakdown of how the architecture works under the hood and the technical challenges I ran into.
1. The Core Architecture: Zero Server Uploads
Most online image converters are thin web frontends that send files via multipart/form-data to a backend server running Sharp, ImageMagick, or FFmpeg.
In contrast, IMG Free Toolkit processes raw byte arrays directly in the client browser:
[ User File ] ──> [ ArrayBuffer ] ──> [ Web Worker / WASM ] ──> [ Blob / Object URL ]
- Privacy by design: Because the file never leaves the user’s device, sensitive documents (visa photos, tax receipts, medical scans) can be safely processed without cloud interception risks.
- Near-zero infrastructure bills: The entire platform is hosted statically via a global CDN. Serving 100,000 users incurs virtually the same zero-compute cost as serving 10 users.
2. Offloading CPU Work to Web Workers & OffscreenCanvas
Compressing high-resolution 20MB+ mobile camera files involves heavy iterative calculations over millions of raw RGBA pixel values. Running that on the main thread freezes the DOM, causes scroll stuttering, and triggers browser "Page Unresponsive" alerts.
To keep the UI responsive at 60 FPS, all heavy encoding tasks run inside background Web Workers:
// Offloading image encoding off the main UI thread
const worker = new Worker(
new URL('./workers/compressor.worker.js', import.meta.url)
);
worker.postMessage({
fileBuffer,
quality: 0.8,
targetSizeKB: 100,
mimeType: 'image/webp'
});
worker.onmessage = (event) => {
const { compressedBlob, savingsPercent } = event.data;
// Instantly update the side-by-side comparison slider
};
Where browser support allows, the worker draws directly into an OffscreenCanvas, computing lossy binary approximations without touching the main UI thread.
3. Format Conversions with WebAssembly (WASM)
While modern browsers natively support JPEG, PNG, and WebP, other formats present hurdles:
HEIC / HEIF: Default on iOS devices, but unsupported natively in most non-Safari desktop browsers.
AVIF: High-efficiency modern codec, but native decoding speed varies significantly across platforms.
To solve this, I compiled C/Rust format encoders into WebAssembly binaries. The browser instantiates the WASM module inside the Web Worker, decodes the raw image stream into raw pixel arrays, and hands it back to the canvas pipeline for re-encoding into standard web-friendly formats.
4. On-Device OCR with Client-Cached Language Models
For the Image-to-Excel and Image-to-Word tools, I integrated Tesseract.js.
Instead of routing user screenshots to an external computer vision cloud API, the browser downloads the trained OCR language models once and caches them via the Cache Storage API / IndexedDB. Optical character recognition executes locally, parsing tabular structures directly into client-generated .xlsx or .csv files.
- Engineering Challenges & Lessons Learned
Building a desktop-grade suite inside a browser sandbox came with real edge cases:
Mobile Safari Memory Ceilings: Attempting to batch process a dozen 30MB photos simultaneously on iOS will cause WebKit to aggressively terminate the tab due to RAM limits. I built a dynamic task scheduler that throttles worker concurrency based on navigator.hardwareConcurrency and downsamples preview buffers.
Native Canvas vs. WASM Encoders: Native canvas.toBlob() is blazingly fast for basic conversions, but compiled WASM encoders (like MozJPEG) produce noticeably smaller file sizes at identical visual quality. Balancing initial WASM bundle download size against compression efficiency is an ongoing tuning process.
Live Demo & Feedback
You can test the suite live here: IMG Free Toolkit
Try dropping a 5MB+ image into the compressor with your browser's DevTools Network tab open—you'll see that zero bytes of image data are sent over the wire.
I’d love your feedback:
What image workflows or formats would you like to see added next.
How are other developers handling low-memory detection in Web Workers on mobile?
P.S. As mentioned, I’m currently looking for new opportunities! I specialize in Next.js/React architecture, WebAssembly, and client-side performance. If your team is hiring or needs specialized contract consulting, feel free to reach out via my profile.
