The browser sandbox wasn't designed to make you safe on the internet. It was designed to stop a very specific thing: a malicious web page from being able to install software on your computer. That's a narrow goal, deliberately so, and understanding what it actually protects against and what sits completely outside its scope changes how you should think about any tool that claims to be "safe because it runs in your browser."
The Problem That Triggered the Architecture
Before 2008, every major browser ran its entire operation inside a single process. JavaScript execution, page rendering, file handling, network requests: all of it shared the same memory space and, critically, the same access privileges as the user who launched the browser. According to the original Chromium security architecture paper published by researchers at UC Berkeley and Stanford, most web browsers employed a monolithic architecture that combined "the user" and "the web" into a single protection domain. An attacker who exploited an arbitrary code execution vulnerability in such a browser could steal sensitive files or install malware.
This wasn't a hypothetical. Drive-by downloads in the mid-2000s routinely exploited browser vulnerabilities to silently install malware without any action from the user beyond visiting a page. The attacker's path was short: find a memory corruption bug in the browser's rendering engine, exploit it to gain code execution, and then, since the renderer was already running with full user privileges, access the file system, write executables, and persist.
The Google security team building Chrome saw this as an architectural problem, not just a bug-count problem. Patching individual vulnerabilities was not going to stop the category of attack. They needed to make the consequence of a successful exploit significantly less severe, so that even if an attacker found and exploited a zero-day in the renderer, the damage was contained.
How the Architecture Responded
Chromium's answer, as detailed in its published security architecture paper, was two modules in separate protection domains: a browser kernel, which interacts with the operating system, and a rendering engine, which runs with restricted privileges in a sandbox. The renderer, the component that parses HTML, executes JavaScript, and builds what you see on screen, was deliberately stripped of the ability to access the file system, launch processes, or make direct system calls. It can draw pixels. It can communicate with the browser kernel process through a tightly controlled inter-process communication channel. That's roughly it.
The in-scope goals of Chromium's architecture focused on preventing an attacker from achieving three high-value targets: installing persistent malware on the user's computer, reading private files without authorization, and making changes to the host system that survive browser restarts. The renderer process was rendered incapable of doing any of those things directly, even if an attacker had successfully exploited it.
The browser kernel process, the privileged component that mediates everything the renderer needs access to, acts as a gatekeeper. When the renderer needs to display content on screen, it sends a bitmap to the browser kernel, which paints it into the window. When JavaScript on a page wants to read a local file through something like a file input element, the browser kernel handles that request and only passes back what the renderer is permitted to see. The renderer never touches the operating system directly.
This design is why we can say, genuinely and not just as a marketing claim, that our tools process your files inside the browser's sandboxed environment. When you drop an image into our Local Image Converter or paste JSON into our JSON Formatter, that data is being handled by the renderer process: the one that doesn't have file system write access, can't launch executables, and can't persist anything beyond the current tab.
What Site Isolation Added
The original sandbox design drew a boundary between the browser and the operating system. It didn't draw boundaries between different websites running in the same browser. In 2018, when the Spectre and Meltdown CPU vulnerabilities became public, a new problem became visible: JavaScript running in one tab could potentially read memory belonging to another tab or even the operating system through speculative execution side-channel attacks, without ever escaping the sandbox in the traditional sense.
Chrome's response was Site Isolation, enabled by default in Chrome 67, which ensures pages from different websites are always placed in separate processes, each running in its own sandbox. According to Chromium's own Site Isolation design document, this was specifically designed to defend against Spectre and Meltdown side-channel attacks. Even if a malicious page was theoretically capable of reading memory contents through timing-based speculation, it would only be able to read memory belonging to its own isolated process, not cross-site data.
The design document also describes the security assumption explicitly: an attacker can convince the user to visit a page that exploits a vulnerability in the renderer process, allowing the attacker to run arbitrary code within the sandbox. Site Isolation ensures that even at that point, the attacker can't access cross-site data.
What the Sandbox Still Can't Prevent
This is the part that doesn't appear prominently in most "your browser is safe" explanations, and it matters.
The sandbox is a software boundary enforced at the operating system level. Some attacks don't target the sandbox mechanism at all. They target the hardware directly. Rowhammer.js, for example, uses malicious JavaScript to inject faults into neighboring system memory cells at the hardware level, bypassing all OS and sandbox memory access restrictions. Research published at USENIX Security documents this category of attack, where the technique doesn't attack the sandbox but instead targets machine hardware directly. The sandbox can't stop an attack that operates below the layer where the sandbox exists.
Sandbox escapes, meaning bugs in the sandbox implementation itself, are a persistent and real category of vulnerability. CVE-2025-2783, a sandbox escape in Chrome's Mojo IPC layer on Windows rated CVSS 8.3, was patched in March 2025 and added to CISA's Known Exploited Vulnerabilities catalog. Kaspersky researchers documented real-world exploitation where infection occurred immediately after a victim clicked a link in a phishing email, with no further user interaction required, with the flaw allowing attackers to bypass Chrome's sandbox protection as if it didn't exist.
The sandbox also doesn't protect against what you voluntarily give it. If a webpage asks for your location, your camera, or microphone access and you grant it, that data flows outside the sandbox boundary through intentionally designed permission APIs. If a tool on a webpage sends an HTTP request with your data in the payload, that's the renderer process doing exactly what it's allowed to do: communicate through the browser kernel to the network. The sandbox stops unauthorized access to your system. It doesn't stop authorized outbound requests that were the tool's purpose all along.
This is the distinction that actually matters for evaluating browser-based tools. A tool that claims to be private "because it runs in the browser" isn't making a meaningful privacy claim unless the claim is specifically that it makes no outbound network requests with your data. The sandbox guarantees that a malicious tool can't quietly install software on your machine. It doesn't guarantee that a legitimately functioning tool isn't sending your content somewhere while it works. Those are very different assurances.
The Network Tab Test
The way to verify the specific claim, that a tool processes data locally without transmitting it, isn't to trust the sandbox exists. It's to open your browser's developer tools, switch to the Network tab, and watch what happens while you use the tool. A client-side tool that genuinely processes data without a server generates no outbound fetch or XHR requests while it's doing its work. The assets load when the page loads. After that, silence.
Our tools at Edotpocket, including the JSON Formatter, the Word Counter, the Image Color Picker, and the Local Image Converter, generate no outbound data requests during operation because there's no server in their processing pipeline. You can verify this yourself in the Network tab. The sandbox is one layer of that assurance: your data can't be written to your file system or used to execute anything on your machine by code running in the renderer. The absence of network requests is the separate, checkable assurance that your data isn't going anywhere over the wire either.
What This Means in Practice
The browser sandbox is a genuinely significant piece of security engineering. As the original Chromium architecture paper states, the design helps mitigate high-severity attacks without sacrificing compatibility with existing websites. For the threat it was designed against, a web page exploiting a browser vulnerability to install persistent malware, it has held up well for nearly two decades, with individual escape vulnerabilities requiring constant patching but the underlying model remaining sound.
But it's not a general-purpose privacy guarantee. It doesn't prevent fingerprinting, it doesn't block authorized network requests, and it can't stop hardware-level side-channel attacks or its own implementation bugs when those are found and exploited. Knowing what the sandbox actually does lets you evaluate "runs in your browser" claims with the right precision: it means your system is protected from unauthorized modification by that code, not necessarily that your data stays with you. Those two things are worth keeping separate.