Running LLMs in the Browser: Can Privacy Be Verified Instead of Promised?

Running a large language model inside a browser tab is now a supported, shipping configuration across all three major engines, but the privacy pitch attached to it, “your data never leaves the device,” remains a vendor promise rather than a checkable property. The GPU context, the model bytes, and every network call in that tab belong to the host page, not to you. Until verification mechanisms exist and ship, enterprises should treat in-browser inference as a policy decision, not a compliance control.

What actually runs in the page when a browser runs an LLM?

The execution substrate for in-browser AI is WebGPU, a JavaScript API (with Rust, C++, and C bindings) for cross-platform GPU access that sits on top of the system’s native Vulkan, Metal, or Direct3D 12 drivers, and that explicitly targets AI and machine learning workloads alongside graphics (Wikipedia’s WebGPU entry).

WebGPU replaces WebGL, which was a JavaScript port of OpenGL ES 2.0 designed for drawing triangles. The new API is a general-purpose architecture compatible with modern GPU programming models, and its defining feature for this discussion is first-class support for GPGPU computation: compute shaders as a primary citizen, not a hack bolted onto a rendering pipeline (MDN’s WebGPU API reference). The matrix multiplications in a transformer forward pass are the kind of workload the compute path serves.

The shader language is WGSL, the WebGPU Shading Language. WGSL has its own history worth knowing: it was originally designed to be trivially translatable to SPIR-V, the Vulkan intermediate representation, until complaints from the community redirected it into a more conventional shading-language design. The compilation layer the references name is Tint, a Google-made compiler for WGSL, with Naga as the counterpart developed for the Rust wgpu stack that webgpu.org lists as Firefox’s implementation. None of the sources surveyed here states which compiler a given browser actually invokes at runtime, and that layer is exactly what an execution audit would have to inspect to check what shader code ran on the GPU.

Two details in that stack matter for the privacy question later. First, every layer between the model weights and the silicon (the API, the shader language, the compiler, the driver translation to Vulkan, Metal, or D3D12) is controlled by software the user did not choose and cannot easily inspect from inside the tab. Second, the API was designed for capability and portability. Confidentiality of what flows through it was not a stated design goal, and nothing in the specification text documented by MDN provides one.

Who owns the GPU when a model runs in your tab?

The host page owns it. That is this article’s reading of the trust model rather than a sentence from any source surveyed, and none of those pages states it either way. On that reading, a page’s JavaScript obtains a logical device and uses it for every buffer, queue, and pipeline it runs on the GPU, and the boundary of the abstraction is the page. It is not the user, not the model, and not the data.

Read that sentence again with a security reviewer’s eyes, because it inverts the mental model most “local AI” marketing relies on. The pitch frames the device as yours: your laptop, your GPU, your data. The API frames the device as the page’s: the origin that requested the device gets the queues, the buffers, and the pipelines. The model weights are bytes the page fetched (from wherever it chose), uploaded into buffers it owns, and executed through pipelines it compiled. Your prompt is data the page reads from its own DOM and writes into buffers it controls. Every output token flows back through JavaScript the page author wrote.

This is not a flaw to be patched. It is the trust model, and it is the same trust model the web has always had: you extend ambient authority to an origin when you load it. What changed is the marketing. When the origin was serving you a document, “the page controls the page” was unremarkable. When the origin is serving you an inference engine and telling you the computation is private because it happens on your hardware, the gap between the trust model and the pitch becomes the entire story.

The practical consequence: “local execution” and “private execution” are independent properties. Local execution is verifiable in principle (you can watch the network tab, at least crudely). Private execution against the host page’s own code is not a property the current web platform offers at all.

Which browsers ship WebGPU, and how final is the standard?

All three major engines ship WebGPU as of mid-2025, but the specification itself is still a W3C Candidate Recommendation, not a final Recommendation, which means the API is deployable but not done (Wikipedia).

The rollout timeline, per Wikipedia’s engine-by-engine accounting:

Wikipedia names Chrome’s launch backends explicitly and says nothing about Safari’s or Firefox’s, so the not-stated cells above are the sources’ silence, not a claim that no backend exists. Safari and Firefox arriving in mid-2025, two years after Chromium, is the reason “runs in any modern browser” only became an honest claim recently, and it means a stack targeting 2026 browsers can assume WebGPU support rather than treat it as a demo target.

Standards maturity matters here for a subtler reason than API stability. A Candidate Recommendation with a privacy-relevant trust model baked in is a window: once WebGPU reaches final Recommendation with that page-scoped device model entrenched across three engines, changing the trust boundary becomes a multi-year coordination problem. If verifiable execution is ever going to be a platform feature rather than a per-vendor bolt-on, the argument for it has to land before the spec calcifies.

What are the 2026 in-page inference stacks actually shipping?

The public ecosystem pages give a blunt answer: graphics first, inference a short list, verification nowhere. webgpu.org’s machine-learning section names exactly three runtimes, TensorFlow.js, ONNX Runtime, and Apache TVM, followed by a “many more” link. The community site at webgpu.com is a showcase of graphics work: Three.js expeditions through ancient Egypt, PlayCanvas cinematics about AI infrastructure, an open-source WebGPU particle-life instrument. Neither page, as of early September 2026, describes anything resembling a mechanism for verifying what an in-page model did with its inputs.

The runtimes that exist are dispatch layers. TensorFlow.js, ONNX Runtime, and TVM get tensors into GPU buffers and answers back out, and the ecosystem pages advertise them on capability and portability. That is not a criticism of the projects. It is a measurement of where the ecosystem’s effort has gone. Performance and portability got the engineering. Verifiability got a marketing sentence.

Where does “your data never leaves the device” break?

It breaks at the host page, which on the reading above controls the GPU device, the model bytes, and every network call in the tab, so the claim is only as strong as your trust in the origin serving the page.

Map the exfiltration paths an in-page inference deployment actually exposes, using only what the platform gives the page by default:

Network egress. The page that runs the model can also call fetch, open WebSockets, or stream via WebRTC. Nothing in WebGPU intersects with the network stack at all. A page can run your prompt through a local model and POST the transcript to an endpoint in the same event loop tick, and the only thing stopping it is the page author’s restraint, your network monitor, or an enterprise egress policy that treats the browser as untrusted anyway.

Model provenance. The weights are bytes the page chose. You have no platform-level way to confirm that the model in GPU memory is the model the vendor’s blog post benchmarked, rather than a fine-tune with an extra system-prompt behavior or a quantization that leaks through a side channel. Hash pinning is possible in principle for a page that volunteers it; nothing requires it.

The page perimeter itself. Service workers and browser extensions operate adjacent to, or across, page boundaries. The documentation surveyed does not cover either interaction, so treat this as an open audit question rather than a documented hole: an enterprise approving “local” browser inference has no spec text to point at that scopes the GPU trust boundary against the rest of the browser’s extension and worker surface.

Telemetry in the weights and runtime. If the model artifact or the inference runtime carries its own reporting behavior, it executes with the page’s ambient authority. The shader compilation layer is exactly where an execution audit would have to look.

The pattern across all four paths is the same: the boundary the API enforces (page versus GPU) is orthogonal to the boundary the privacy pitch implies (your data versus everyone else). The pitch is not lying about where computation happens. It is silent about who else is in the room.

What would verifiable privacy have to check, and does anything check it?

Verifiable browser-inference privacy would need to make three properties checkable: which model bytes executed, what the runtime did with inputs and outputs, and whether the host page stayed inside a declared behavior envelope. No shipping stack checks any of the three.

Turning that privacy from a policy claim into a verifiable property is the right target. What can be evaluated now, from the platform documentation, is the shape of the problem any verification mechanism would have to solve.

Start with what verification would have to pin down, taking the page-scoped device model read above as the premise. If the logical device belongs to the page, an attestation about “the model” has to be anchored somewhere the page cannot forge, which already puts the mechanism in tension with that trust model. Provenance checking means binding weight bytes to a published hash before upload and ideally after, since buffers are mutable and the page owns the queues. Telemetry auditing means observing or constraining the network calls the page makes during inference, which is a service-worker- and extension-shaped problem the GPU API does not touch. Host-page isolation, the strongest version, means the inference context runs somewhere the embedding page cannot read, which no current web primitive provides for GPU compute.

Against that checklist, the current vendor posture is policy copy. Mozilla states that Firefox’s AI features are “optional by design and will remain that way”, which is a product-page commitment. It may well be honored, and Mozilla has a longer track record on this than most vendors, but a sentence on a marketing page is not a checkable execution property, and Mozilla’s own phrasing does not claim to be one.

This is the gap any verification work has to close, and the honest assessment is that the platform gives it almost nothing to build on. The fix is not a better promise. It is a mechanism, and mechanisms in the web platform take years.

What can enterprises honestly deploy today?

In-browser LLM inference is deployable across all three engines right now, but every privacy assurance in the current stack is a policy statement, not a property, so deployments should be gated on vendor posture and contract terms, and “never leaves your device” should be treated as an unverifiable claim until checkable mechanisms exist.

That verdict has operational teeth. If a compliance framework requires that personal data not leave controlled infrastructure, in-browser inference does not currently satisfy it in the verifiable sense, because the entity you would be trusting is the origin serving the page, and the platform provides no way to check that origin’s runtime behavior against its claims. What you can do today: pin and audit the exact page bundle and model bytes served (at your own effort, since nothing enforces it), assert egress controls at the network layer for managed devices, prefer vendors whose contracts put liability behind the privacy claim, and treat Mozilla-style “optional by design” language as a statement of intent rather than evidence.

What you cannot do today: hand an auditor a property. There is no attestation, no provenance binding, no scoped isolation for GPU compute, and no telemetry audit surface in any of the stacks surveyed. The strongest limitation on this whole analysis is worth stating plainly: the sources surveyed are API documentation, standards references, vendor pages, and community showcase listings, all of which predate or ignore the verification question. Absence of verification mechanisms in those pages is weak evidence of absence everywhere. If someone ships a working mechanism, this picture changes on exactly the axis that matters.

Until then, the accurate sentence for a deployment review is the flat one: the computation is local, the trust is not. The GPU does what the page tells it, and the page is someone else’s code. Verification would fix that. Promises have not.

Frequently Asked Questions

Does WebGPU support differ between Chrome, Safari, and Firefox in ways that affect LLM inference?

Chrome 113 launched with explicit backend support for Direct3D 12, Vulkan, and Metal, while Wikipedia does not specify the launch backends for Safari 26 or Firefox 141. This asymmetry means performance benchmarks from Chromium-based browsers may not translate directly to Safari or Firefox, requiring separate profiling for each engine’s specific driver translation layer.

How does the W3C Candidate Recommendation status of WebGPU impact enterprise compliance documentation?

Citing WebGPU as a ‘W3C standard’ in compliance documents is technically inaccurate because the specification is still a Candidate Recommendation, a stage where the API can still change. Enterprises should cite the specific maturity level to avoid audit findings regarding reliance on unstable specifications, distinguishing it from final Recommendations that carry stronger stability guarantees.

What specific compiler layer must an execution audit inspect to verify shader behavior in WebGPU?

Audits must inspect Tint, the Google-made compiler for WGSL, or Naga, the counterpart for the Rust wgpu stack, because these layers translate high-level shader code into the GPU’s native instructions. The body notes that sources do not state which compiler a given browser invokes at runtime, making this a critical unknown for verifying that the intended model logic, rather than modified code, executed on the hardware.

Why is ‘local execution’ insufficient for proving ‘private execution’ in browser-based LLMs?

Local execution is verifiable by observing network traffic, but private execution against the host page’s own code is not a property the current web platform offers. The host page retains ambient authority over the GPU device, model bytes, and network calls, meaning it can exfiltrate data via fetch or WebSockets without violating the local execution constraint, a gap that policy promises do not address.

What operational controls can enterprises implement today to mitigate the lack of verifiable privacy in browser inference?

Enterprises can pin and audit the exact page bundle and model bytes served, assert egress controls at the network layer for managed devices, and prefer vendors whose contracts place liability behind privacy claims. These measures treat the browser as an untrusted environment, compensating for the absence of platform-level attestation or scoped isolation for GPU compute.