Why Mozilla opposes the Chrome Prompt API

If you’ve been tracking the latest browser standards, you’ve likely seen the friction surrounding the proposed Prompt API. Mozilla recently issued a formal "negative" position on this Chrome-led initiative, and frankly, they’re right to be skeptical. When Google pushes for browser-native AI hooks, the industry tends to cheer for innovation, but we need to look at the architectural cost of baking LLM access directly into the DOM.

The Prompt API aims to provide a standardized way for web applications to interact with local large language models. On the surface, it sounds like a developer’s dream: consistent, high-performance AI access without needing to ship massive WASM blobs or rely on external API calls. However, the reality is far more complex. By standardizing this, we aren't just adding a feature; we are effectively turning the browser into a proprietary AI runtime.

The hidden cost of browser-native AI

Here’s where most people get tripped up: the assumption that "native" always equals "better." When you expose an LLM interface directly through the browser, you create a massive new surface area for fingerprinting and privacy abuse. If a site can query a local model, it can potentially infer user intent, sentiment, or even sensitive data based on how the model responds to specific, hidden prompts.

Mozilla’s opposition isn't just about being contrarian; it’s about the long-term health of the open web. If we allow browser vendors to dictate how AI models are accessed, we risk creating a fragmented ecosystem where your web app works perfectly in Chrome but breaks or behaves unpredictably in Firefox or Safari. This is the same "embrace, extend, extinguish" pattern we’ve seen before, just dressed up in modern AI clothing.

Why does browser-native AI matter for developers?

You might be wondering, "How to fix AI integration issues if we don't use the Prompt API?" The answer lies in keeping the AI layer decoupled from the browser engine. By using standard WebAssembly or WebGPU interfaces, you maintain control over your model, your weights, and your data privacy. Relying on a browser-provided API ties your application’s core logic to the whims of a single vendor’s roadmap.

Consider the following risks before you commit your stack to a vendor-specific API:

• Vendor Lock-in: Your application becomes dependent on the specific model version and prompt behavior provided by the browser.
• Privacy Leakage: Browser-native APIs often lack the granular permission controls required to prevent malicious sites from probing your local model.
• Standardization Lag: If the API changes, you’re at the mercy of the browser vendor’s update cycle rather than your own deployment schedule.

The path forward for the open web

This isn't to say that local AI in the browser is a bad idea. It’s actually the future of performant, private web applications. But the implementation matters. We need cross-browser AI standards that prioritize interoperability over convenience. If we rush into a proprietary solution, we’ll spend the next decade trying to patch the security holes and compatibility issues we created today.

The best approach is to build your AI features using open, hardware-accelerated standards like WebGPU. This gives you the performance you need without sacrificing the independence of your application. Don't let the allure of a "simple" API blind you to the architectural debt you’re taking on.

Mozilla’s stance is a necessary check on the rapid, often reckless, pace of browser-native AI development. If you’re building for the long term, prioritize portability over the latest Chrome-exclusive feature. Read our breakdown of WebGPU performance to see how you can achieve similar results without the vendor baggage.