Building In-Browser Private Tools: When the Server Is the Liability

Most file tools on the web work the same way: upload the file, process it on a server, download the result. That made sense when browsers were weak. It doesn't anymore. If your tool views, searches, converts, or exports a user's own file, it can often run entirely in the browser, and then the file never leaves the user's machine.

Why skip the server

An uploaded file becomes your liability: storage, retention, deletion, breaches. The user can't verify any of it. If the file never arrives, there's nothing to leak. That's privacy by architecture, not by policy.

The toolkit

• File API and Blob.slice() to read huge files in chunks with bounded memory.
• Web Workers to parse without freezing the UI.
• WebAssembly when an existing Rust or C parser beats rewriting one in JS.
• IndexedDB or OPFS to store a local index, not the whole file.
• Blob URLs to hand exports back without touching the network.

Example: read mbox

Google Takeout gives you your Gmail as one huge .mbox file that nothing on Windows or Mac can open. Most "online" viewers want you to upload it. readmbox.com reads, indexes, and searches it right in the tab instead. What I like about it:

• No upload endpoint exists, so there's no server to send your mail to.
• Files of tens of gigabytes work, because they're read in chunks.
• No install and no account.
• Exports (CSV, PDF, EML, split MBOX, attachments) are generated locally too.

It does use analytics and says so openly. The claim is scoped precisely: your email never leaves your machine.

Make it verifiable

Load the page, turn off Wi-Fi, then open a file and use it. If it still works, the data isn't going anywhere. You can also watch the Network tab in DevTools, and enforce the guarantee with a strict connect-src in your Content Security Policy so nothing can quietly start uploading later.

Before you add an upload button

Ask whether the file really needs to leave the user's device. Often it doesn't. Every file you never receive is one you can't lose.

Building local-first tools? I'd like to see them in the comments.