Client-Side vs Server-Side File Processing: What a Browser Can and Cannot Do

When you drop a PDF onto a web page and get a smaller one back, one of two things happened. Either the file travelled across the internet to a machine you have never seen, was processed there, and came back — or it never left the tab, and everything happened on your own processor. Both look identical from the outside. A progress bar spins, a download appears.

Which one it was is the single thing worth understanding about online file tools, because it decides who has ever had a copy of your file. This guide explains how in-browser processing actually works, exactly what FileWash runs locally and with which libraries, and — the part that gets left out of privacy marketing — the jobs for which a server is genuinely the better machine.

The only difference that matters

Server-side processing means the bytes of your file are read out of your disk, sent over the network, written to storage on a machine belonging to someone else, opened by software you cannot inspect, and a result is sent back. Everything else about the architecture — how fast it is, how it scales, what it costs the operator — follows from that one fact.

Client-side processing means the file is handed to JavaScript running inside the page you already loaded. It is read into your device’s memory, transformed there, and written back out as a download. No request carries the file. The operator can be curious, careless or compelled by a court, and it changes nothing, because the operator never had it.

This is not a claim about anyone’s integrity. Server-side tools run by serious companies are usually run carefully. It is a claim about what has to be trusted: in one architecture you are trusting a policy, in the other you are trusting a mechanism you can check yourself in about a minute. If you want the method for checking, it is in how to check whether an online file tool is actually uploading your files.

What the browser gained

In-browser file processing is not new, but it only became practical for real work once four pieces were in place.

The File API is what lets a page touch a local file at all. MDN describes it plainly: it “enables web applications to access files and their contents,” and those files become available “when the user makes them available, either using a file <input> element or via drag and drop.” The page receives a File object exposing the name, size, type and last-modified date, and can read the bytes through FileReader. What it cannot do is go looking — the page sees the file you chose and nothing else on your disk (MDN, File API).

The Canvas API is the browser’s general-purpose pixel surface. MDN lists photo manipulation and real-time video processing among its uses. In practice, if you can decode an image into a <canvas>, you can resize it, crop it, rotate it, draw over it, and re-encode it to a different format — all with the codecs the browser already ships to render web pages (MDN, Canvas API).

Web Workers solve the problem that made early attempts feel broken. A worker runs script “in background threads,” so it “can perform tasks without interfering with the user interface.” Without one, a long compression loop freezes the whole tab. Workers cannot touch the DOM, and data crossing into them is copied rather than shared, unless you use transferable objects, which move an ArrayBuffer across “with a zero-copy operation” — relevant when the thing you are passing is a 30 MB file (MDN, Using Web Workers).

WebAssembly is what let decades of existing C and C++ file-format code move into the browser instead of being rewritten. MDN calls it “a low-level assembly-like language that brings near-native performance to the web,” serving “as a compilation target for languages like C/C++, C#, and Rust” (MDN, WebAssembly). Image decoders, PDF renderers and machine-learning runtimes that took years to write did not have to be reinvented in JavaScript.

What FileWash actually runs, library by library

It is worth being specific here rather than saying “powered by WebAssembly,” which is the kind of phrase that sounds like an answer and is not one. These are the actual dependencies, and what each does.

• pdf-lib — pure JavaScript. It parses and rewrites PDF structure, which is what merging, splitting, rotating and page assembly amount to.
• pdfjs-dist (Mozilla’s PDF.js) — renders PDF pages to a canvas. It is mostly JavaScript, running in its own worker, but it does ship WebAssembly modules for specific decoding jobs: JPEG 2000, JBIG2 and colour management.
• browser-image-compression — canvas-based resizing and re-encoding, with the work moved into a Web Worker. No WebAssembly involved.
• heic2any — decodes Apple’s HEIC photos using a build of the libheif library compiled to JavaScript, so HEIC conversion works in browsers that cannot natively open the format.
• @imgly/background-removal — the only genuinely heavy one. It runs an image segmentation neural network through ONNX Runtime Web, which executes the model as WebAssembly.
• jsPDF, JSZip, qrcode, file-saver and a small PDF encryption library handle document assembly, batch downloads as a ZIP, QR codes and password protection respectively.

So the accurate summary is: most of what FileWash does is plain JavaScript plus Canvas, with WebAssembly used in a few specific places where it is the right tool. Two honest caveats follow from reading the code. PDF.js loads its worker script from a public CDN rather than from our own server — that is a script download, not a file upload, but it is a network request that happens while you are working. And metadata stripping works by redrawing the image through a canvas, which discards EXIF as a side effect of re-encoding; it is effective for that purpose, but it does mean the image is recompressed rather than surgically edited.

Where server-side genuinely wins

Pretending otherwise would be marketing. There are several categories where a server is not merely convenient but actually the correct architecture.

Very large files. A server can stream a file from disk, hold a small window of it in memory, and write results back to disk as it goes. A browser tab generally needs its working set resident in RAM, and it is competing with everything else you have open. Past a certain size the browser approach stops being slow and starts failing outright.

OCR. Optical character recognition does run in browsers — there are WebAssembly OCR engines — but a server can use larger models, GPUs, and language data for dozens of scripts without asking every visitor to download any of it. For a 300-page scanned archive in mixed languages, server-side OCR is the sensible choice and it is not close.

Licensed or proprietary engines. Some format handling only exists in commercial libraries whose licences do not permit shipping the code to every visitor’s machine, and browsers do not expose every encoder anyway — what canvas can write out varies by browser. If a job depends on a specific vendor’s rendering engine, that engine lives on a server.

Heavy batch work. Six hundred files with retries, resumability and a report at the end is a queue, and a queue belongs on a machine that will still be running in an hour. Close a browser tab mid-job and the job is gone.

Low-powered devices. Server-side processing has one enormous operational advantage: the operator knows exactly what hardware the code will run on. Client-side code runs on a five-year-old budget phone as readily as on a workstation, and the same operation can succeed on one and fail on the other with no way to predict it in advance.

There is also the plain case where your files already live in a provider’s cloud, or where you need audit logs, versioning and shared access. Those are server products by definition, and no amount of client-side purity substitutes for them.

Memory ceilings, in honest terms

The most common failure of an in-browser tool is running out of memory, and the reason is arithmetic rather than mystery. A JPEG on disk is compressed; to work on it, the browser has to decompress it into pixels. An uncompressed bitmap costs roughly width × height × 4 bytes, so a 4000 × 3000 photo occupies something in the region of 48 MB in memory no matter how small the file was. During processing, several of those can be alive at once: the source bytes, the decoded bitmap, the canvas backing store, and the encoded output.

PDFs behave the same way, one page at a time. Our PDF compressor renders each page to a canvas, encodes it as a JPEG, and adds it to a new document — which also means it turns text into images, so use it when size matters more than selectable text, and see why your PDF is large before assuming compression is the fix at all.

We cannot give you a file-size ceiling, and any site that gives you one for browser processing is guessing. The limit depends on the device’s physical RAM, whether the browser is a 32-bit or 64-bit build, the per-tab memory policy of that specific browser version, how aggressively the operating system reclaims memory, and what else you have open. A PDF that processes comfortably on a laptop can fail on a phone that is also holding a dozen background tabs. The practical advice is unsatisfying but true: try it, and if the tab dies, close everything else or use a bigger machine.

The first-load cost of doing things locally

Local processing moves work to you, and some of that work is a download. The background remover is the clearest example. Nothing about it is fetched when you open the page — the library is loaded on demand, only once you actually drop an image. At that point the segmentation model’s weights are fetched from the library vendor’s CDN, and a neural network’s weights are large compared with a page of application JavaScript.

We will not quote you a size or a time, because we have not measured it and it depends on your connection. What is fair to say is that the first background removal involves a noticeable wait that has nothing to do with your image, and subsequent images in the same session are much faster, because the library keeps the initialised model in memory rather than fetching it a second time. There is also a privacy nuance worth stating rather than glossing: your image is not uploaded anywhere, but fetching the model is a request to a third-party CDN, which sees that a request came from your address. That is a smaller exposure than sending the photograph, and it is not zero.

Server-side tools have the opposite profile — no model download, a fast first run, and an upload proportional to your file every single time.

What “we delete your files after an hour” does and does not mean

Retention promises are common and often sincere, but they answer a narrower question than people read them as answering. Deletion after an hour is a statement about how long a copy is kept. It says nothing about the fact that a copy existed, was transmitted across networks, was written to storage, and was readable in plaintext at the endpoint for the duration.

European data protection law draws the line in exactly that place. Under Article 4(2) of the GDPR, “processing” means:

any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction

(Article 4 GDPR, retrieved 31 July 2026.) Storage is processing. Transmission is processing. Erasure is itself processing. So if the document contains personal data, deleting it later does not undo the processing that already happened — it limits it. That distinction matters most when you are handling someone else’s data rather than your own: a lawyer uploading a client file, or an employee uploading a colleague’s passport scan, has made a disclosure that an hourly deletion timer does not retract.

None of which makes retention policies worthless. A company operating under regulatory supervision with a published policy has real incentives to honour it. But it is a promise you cannot verify from outside, whereas the absence of a network request is something you can observe. Client-side processing does not answer the trust question better; it removes the question.

How to choose, per job

Two questions settle nearly every case. Does the file contain anything you would not email to a stranger? And is it big enough, or the job heavy enough, that a browser will struggle?

FileWash is built for the first two rows, and it is honest about the rest. If your job is genuinely a batch pipeline or a scanned archive that needs OCR, a server-side service or proper desktop software will serve you better, and you should use one. Where the work fits comfortably in a browser, though, running it locally removes an entire category of question you would otherwise have to take on faith.