A few years ago, almost every “online tool” worked the same way: you upload your file to a server, wait for a response, then download the result. Simple, but it has real costs — server bandwidth, storage, latency, and (the big one) your file leaves your device.
Lately more tools are shifting that entire pipeline into the browser itself. No upload, no server round-trip, no storage. Here’s why that shift is happening, and what it actually takes to build a tool this way.
Why client-side processing makes sense
Privacy by default. If a file never leaves the browser, there’s nothing to log, nothing to breach, nothing to accidentally retain. For anything image or document related, this matters more than most devs give it credit for.
Cost. Every file processed server-side costs compute and bandwidth. Processed client-side, it costs the user’s device — which for most modern browsers is more than capable.
Speed (once loaded). No round-trip to a server means processing starts the instant the user drops a file in.
The tradeoff: initial load time. Shipping a WASM runtime or an ML model to the browser means a heavier first load. That’s the real engineering problem to solve, not whether it’s possible.
A concrete example: background removal
Background removal used to be squarely a server-side task — you’d send an image to an API (Remove.bg style), it’d run a segmentation model, and send back a cutout PNG.
It’s now genuinely possible to do this entirely client-side using ONNX Runtime Web, which lets you run trained ML models directly in the browser via WASM (with WebGPU as a faster path where supported). The rough architecture:
- Convert your segmentation model to ONNX format
- Ship
onnxruntime-weband the model file to the client - Run inference in a Web Worker (keeps the UI thread free)
- Feed the output mask back into a canvas to composite the cutout
The tradeoff is exactly what you’d expect: the model + runtime is a few hundred KB to a few MB, so you eat that cost once per session, then everything after is instant and local. For a tool people use once and leave, that’s a very reasonable trade.
I ended up implementing this on a small tools site I maintain — mostly as a way to actually test this pattern in production rather than just in a demo. Happy to answer questions if anyone’s exploring the same approach for their own projects.
Where this pattern works well (and where it doesn’t)
Works well:
- Image manipulation (compression, background removal, format conversion)
- Text/document utilities (word counters, formatters, converters that don’t need OCR)
- Anything where “your data never leaves your device” is a genuine selling point
Doesn’t work well:
- Anything needing a large, frequently-updated dataset (client would need to re-download it constantly)
- True heavy-duty processing (video encoding at scale, for instance) where mobile devices and older hardware will choke
The takeaway
This isn’t a “server-side is dead” post — plenty of workloads still belong there. But for a specific class of tools (files in, files out, no huge dataset dependency), pushing the work to the browser is now a legitimately better default than it was five years ago, mostly thanks to WASM and WebGPU maturing.
If you’re building something in this space, curious what stack you’re using — vanilla WASM, ONNX Runtime, TensorFlow.js, something else?
답글 남기기