A conventional document tool has a simple shape: upload, process on a server, download, delete later. Every step of that shape is a risk and a cost.
The boundary is the architecture
When processing happens in the browser, the data boundary is the device. There is no retention window to define, no storage breach to disclose, no third-party processor in the chain.
What remains is the hard engineering: making browser primitives fast enough, memory-safe on large files, and correct across browsers.
What it costs
Client-side processing gives up server compute and centralised analytics. Heavy operations must be chunked, and the interface has to communicate progress honestly.
We accept that trade because the alternative is asking users to surrender private files to an unnamed server for a task their own machine can perform.
Where it does not apply
Not every workload belongs in the browser. Collaborative data, shared records and anything requiring an audit trail on a server need a server. The discipline is deciding which side of the boundary each operation belongs on — and documenting it.
That decision is the first page of every architecture document we write.