Uploading a file before you can process it is a habit servers taught us. Count the things people actually do to images day to day — shrink them, change format, cut out a background, build a short animation, pull the text out — and most of it the browser can do on its own. We spent a while moving those in one at a time, and hit a boundary that isn't pretty. Up front: I own the client-side codec and model-loading side of this. The matting algorithm and the PDF engine aren't mine, so where those come up I'll stick to what I observed.
Why not put it on a server
Because we don't want to touch your images. Nearly every online image tool works the same way: upload, process, download. Once the file is on someone else's server, how long it stays, who can read it and whether it's really deleted all come down to their word. A privacy policy is a promise, and a promise can't be verified. Meanwhile the things people most need to process are exactly the things that shouldn't travel — IDs, contracts, unreleased product shots, anything with a face in it. Running in the browser sidesteps all of that: the file never leaves your machine, and unlike a promise, that claim can be checked. Open DevTools, go to the Network tab, process an image. No upload request. The preview's src is a blob: URL — an object in your own browser's memory that never touched the network. Ten seconds, and worth more than a page of policy text.
