How it works
Files never leave your device. Here's exactly what happens when you convert.
What happens when you drop a file
Your browser reads the file
The browser's File API reads your file into memory as an ArrayBuffer. No network request is made. The data stays in your browser tab's isolated memory.
A WASM module processes it
The relevant WebAssembly module (libvips for images, ffmpeg for video, etc.) is loaded once and cached. On first use it downloads; after that it loads instantly from your browser cache. The module runs on your CPU in a sandboxed Web Worker, so it can't access anything outside the tab.
Output is handed back to the browser
The converted file is an ArrayBuffer in memory. The browser creates a local object URL (
blob:) and serves your download from it. Nothing is sent anywhere.Memory is freed
After download, the object URL is revoked and the ArrayBuffers are garbage collected. Your file data is gone from memory. Closing the tab is guaranteed cleanup.
The libraries under the hood
libvips
Images (JPG, WebP, AVIF, PNG, HEIC, TIFF)
A high-performance image processing library, ~5× faster than ImageMagick for most operations. Compiles to ~3MB WASM.
ffmpeg.wasm
Video and audio (MP4, MP3, GIF, WebM, WAV)
The industry-standard multimedia library, compiled to WebAssembly by the ffmpeg.wasm project. Runs inside a SharedArrayBuffer worker.
pdf-lib + mupdf-wasm
PDF creation, merging, splitting, rendering
pdf-lib handles construction and modification in pure JS; mupdf-wasm handles rendering and rasterization.
@huggingface/transformers
AI tools (background removal, upscaling, alt-text)
Runs ONNX models in-browser via WebAssembly and WebGPU. Models are downloaded once, then cached locally.
Why WebAssembly, not JavaScript?
JavaScript is fast for web UI but slow for byte-heavy operations like video encoding or RAW image processing. Native code (C, C++, Rust) is 10–100× faster for these workloads.
WebAssembly is a binary instruction format that browsers compile to native machine code at load time. It runs in the same sandboxed environment as JavaScript but at near-native speed. The WASM security model means a library can't access your file system, camera, network, or anything outside the memory it's given.
The tradeoff: WASM modules are large (libvips is ~3MB, ffmpeg.wasm is ~25MB). We lazy-load them on first interaction and cache aggressively, so you only pay that cost once.
Batch conversion
Every tool runs conversions in a pool of Web Workers — typically 4–8, depending on your device's core count. Files are processed in parallel up to the worker limit, then queued. A 1,000-file batch on a modern laptop finishes in minutes, not hours.
The practical limit is your device's RAM. A 1,000-file batch of 2MB images requires roughly 2GB of working memory at peak. Modern laptops handle this fine; older phones may hit limits around 100–200 files. We surface clear warnings when memory pressure is detected.
Verify it yourself
Open DevTools → Network tab → filter by "XHR/Fetch." Drop a file and run a conversion. You'll see the WASM module load (once), and nothing else. No POST request, no upload, no call home.
This is verifiable, not a promise. The source is what it is.