4 min read

Chrome's Prompt API Now Runs on Web Pages. The Spec Process Disagrees.

Chrome 148 opened the Prompt API to any web page — no extension needed. Mozilla, Apple, W3C, and Microsoft all formally objected before it shipped.

Prompt APIGemini NanoBrowser Standards

Chrome 148 shipped May 5, 2026 with one change worth tracking: the Prompt API is now available to web pages, not just extensions. Any origin can call Gemini Nano from JavaScript — no manifest, no extension, no API key.

The API surface is small. LanguageModel.availability() tells you whether inference can run. LanguageModel.create() opens a session. session.prompt() returns a complete string; session.promptStreaming() returns a ReadableStream. Chrome 148 also adds structured output — responses can be constrained to match a regular expression or a JSON schema — and multimodal input: the session can accept text, images, and audio. Temperature and topK sampling land behind a separate origin trial.

The constraint that surprises: Chrome silently downloads Gemini Nano on first use per origin. Requirements are 22 GB of free disk space, plus either 4 GB of GPU VRAM or 16 GB of RAM with at least 4 CPU cores. Mobile is unsupported. The model currently handles English, Japanese, and Spanish only, and the API does not work in Web Workers.

Call LanguageModel.availability()before any session creation. If the model hasn’t downloaded yet, you’ll block waiting — or you can detect that state and offer a fallback.

Mozilla, Apple, W3C, and Microsoft all filed formal opposition before Chrome shipped. The technical objections are concrete: prompts tuned against Gemini Nano will silently produce different output on Firefox or Safari, because neither has an equivalent embedded model. Unlike a deterministic web API, behavior here depends on which model is bundled in which browser — and those models will diverge. Apple’s WebKit team also noted a resource asymmetry: pages receive free inference while users pay in battery and GPU cycles, with no permission dialog.

The security concern is structural. No privilege boundary separates developer-supplied system instructions from rendered page content. Any text the model reads — comment sections, support tickets, summaries of user-generated content — is a valid injection surface.

What this unlocks: the Prompt API is genuinely useful for offline-capable progressive enhancement where you control the content being processed. Processing untrusted user input is a different situation, and treating it as a cross-browser feature is wrong today — Firefox and Safari compatibility is not on any near-term timeline.

Chrome shipped it anyway. Treat it as progressive enhancement, build the fallback first, and don’t pass untrusted content to the model without treating the output as untrusted in return.

Checking browser support