How Browser-Based Tools Protect Your Data: WebAssembly, Web Workers, and Zero-Knowledge Processing

Explore the technical architecture behind client-side processing — from WASM and Web Workers to sandboxed execution and zero-knowledge design.

• Modern web browsers are among the most sophisticated software platforms ever created. They can render complex 3D graphics, stream high-definition video, run real-time collaboration tools, and — as tools like Bebpop demonstrate — perform heavyweight data processing that was once only possible on dedicated desktop software. Understanding how browser-based tools keep your data secure while delivering this performance requires a look at four key technologies: sandboxed execution, WebAssembly, Web Workers, and the zero-knowledge design philosophy.
• Let us start with the browser's security model itself. Every modern browser implements something called the same-origin policy and a sandboxed execution environment. When you visit a website, the JavaScript and WebAssembly code that runs on that page is confined to a virtual container — a sandbox — that has no direct access to your file system, your operating system, or other browser tabs. This sandbox is enforced at the operating system level by the browser process architecture: each tab runs in its own operating system process, isolated from every other tab and from the system at large.
• This sandbox is not just an abstract concept — it is the foundation upon which all client-side data security rests. Because a web page's code can only interact with what the browser's API surface explicitly allows, a properly designed browser-based tool literally cannot send your files anywhere unless it explicitly initiates a network request. You can verify this yourself: open your browser's developer tools (F12), switch to the Network tab, and use any of the tools on this site. You will see zero outbound HTTP requests during processing. The data never leaves.
• WebAssembly takes this a step further by bringing native-code performance to the browser sandbox. Traditionally, if you wanted to process a PDF or compress an image in the browser, you were limited to JavaScript — a high-level, dynamically typed language that, while incredibly versatile, is fundamentally slower than compiled languages like C++ or Rust for CPU-intensive operations. WASM changes this by providing a compile target for these languages that runs in the browser at near-native speed, all while remaining inside the same security sandbox.
• For Bebpop, WASM means we can use the same proven libraries that server-side tools rely on — libraries like pdf.js for PDF rendering, libjpeg-turbo for image compression, and zlib for general-purpose compression — compiled to run directly in your browser. There is no watered-down JavaScript reimplementation; it is the same battle-tested C and Rust code, compiled to WASM, executing on your machine with the same efficiency it would have on a server. But because it runs in your browser sandbox, it has no access to other data on your system and cannot phone home with your information.
• Web Workers solve a different but equally important problem: keeping the user interface responsive during heavy processing. Before Web Workers were standardised, any JavaScript operation longer than about 50 milliseconds would freeze the browser tab, making the page unresponsive and creating a poor user experience. Web Workers are background threads that run JavaScript and WASM code in parallel with the main user interface thread. They communicate with the main thread only through a secure message-passing system, exchanging plain messages — never direct memory references or file handles.
• This message-passing design is a security feature in itself. Because the Worker cannot directly access the DOM, the browser's local storage, or the main thread's variables, there is a strict compartmentalisation of data access. The main thread loads your file, transfers a copy of the data to the Worker, and the Worker processes it in isolation. Once processing is complete, the Worker sends back the result as a message, and the main thread cleans up both the original data and the Worker. This means sensitive intermediate data — decompressed file contents, temporary buffers — exists only in the Worker's isolated memory, not in the globally visible main thread.
• The zero-knowledge design philosophy ties these technologies together into a coherent privacy architecture. A zero-knowledge tool is one that, by its very design, cannot know anything about the data it processes. On Bebpop, this is achieved through a deliberate architectural constraint: the web server that delivers the HTML, CSS, and JavaScript files is completely decoupled from any data-processing logic. The server never sees your file, never stores it, never logs it, and never transmits it. From the server's perspective, your interaction is indistinguishable from someone who loaded the page and never used a tool at all.
• Contrast this with a typical server-side tool. In that model, you are placing trust in the service provider to handle your data responsibly, to secure their infrastructure against breaches, to not retain logs longer than necessary, and to not use your data for purposes you did not intend. Even if the provider is trustworthy — and many are — the data still traverses the public internet, lands on a server you do not control, and is processed by software running in an environment you cannot inspect. The attack surface includes the network path, the server operating system, the processing library, the database, and any third-party services integrated into the pipeline.
• With a client-side tool like Bebpop, the attack surface collapses to a single point: your own browser. The only code that touches your data is the code delivered to your browser in the initial page load, and you can inspect every byte of it using the browser's developer tools. The WASM binaries are open-source or built from well-known libraries. The JavaScript that orchestrates the processing is readable in the Sources tab of your developer tools. There are no network calls, no server databases, no third-party processing APIs, and no data retention policies to trust — because there is nothing to retain.
• Local storage and session management on Bebpop follow the same privacy-first principles. We do not use cookies for tracking, analytics, or user identification. The only browser storage we use is the browser's standard cache to speed up subsequent page loads — and this stores only the tool's code, never your data. If you refresh the page or close the tab, all processing results are discarded. There are no user accounts, no session tokens, and no persistent identifiers. Your visit to the site is anonymous by design, and we intend to keep it that way.
• The transparency of client-side architecture is one of its strongest security advantages. Anyone with basic web development skills can verify exactly what a tool does with their data. The network tab does not lie: if there is no outbound request carrying your file, your file has not left your machine. The Sources tab reveals every line of JavaScript and every WASM module loaded by the page. This transparency is impossible with server-side tools, where the processing logic is hidden behind an API endpoint and you have no way to verify what the server actually does with the data you uploaded.
• In summary, browser-based tools protect your data through a layered security approach: the browser's built-in sandbox isolates process execution; WebAssembly enables native-speed processing without leaving that sandbox; Web Workers keep sensitive data compartmentalised in background threads; and the zero-knowledge design ensures the server never touches your files at all. Together, these technologies make it possible to have professional-grade data processing that is simultaneously faster, more private, and more transparent than the server-side alternatives. The next time you need an online tool, remember: the most secure server for your data is no server at all — it is your own browser.