Prompt API: asking the browser's own model to do a task

A general prompt API beside the purpose built ones

The Prompt API is a proposal for a web API that lets web developers prompt a language model directly, and it sits alongside a family of narrower proposals that the same group is exploring.

Those narrower ones are for specific tasks: a translator and language detector in the translation-api repository, a summarizer, writer and rewriter in the writing-assistance-apis repository, and a proofreader in the proofreader-api repository. The Prompt API is the general purpose one, and the README states the trade in a sentence: it gives web developers access to many more capabilities, at the cost of requiring them to do their own prompt engineering.

That is the central design decision, and it is worth being precise about what it means. A task specific API has already decided what the input looks like, what the output means, and what a failure looks like. A general prompt API hands the developer a string in and a string out, which means the developer owns the prompt, the parsing, and the behaviour when the model returns something unexpected.

The proposal is at an early stage in the standards process. The explainer and the accompanied draft report are in active development by the Web Machine Learning Community Group, whose members are seeking feedback and support for the proposal to gain Working Group and implementer adoption. Implementations are described as experimentally available in Google Chrome and Microsoft Edge.

Why the browser should own the model

The motivation section is the strongest part of the document, because it argues the case twice, against two different alternatives.

Against cloud APIs, the argument is about what leaves the device. The listed benefits are local processing of sensitive data, which allows websites to combine AI features with end-to-end encryption, potentially faster results since there is no server round trip, offline usage, lower API costs for web developers, and hybrid approaches where free users of a site get on-device AI while paid users get a more powerful API-based model.

Against developer-supplied models, the argument is about the user's resources. Using a built-in model can save the user's bandwidth, storage and memory, while using a model that is optimized for the device. It also lowers the barrier to entry for web developers, because they no longer need to serve models and manage dependencies.

The current state of the art that the proposal is reacting to is stated plainly: web developers who wish to use language models must either call out to cloud APIs, or bring their own and run them using technologies like WASM and WebGPU, usually through JavaScript runtime frameworks.

That framing is what makes the proposal interesting beyond the API shape. It is a claim about where a model should live by default, and the hybrid option is the part most teams will actually want.

Four goals and two explicit non-goals

The goals are short and they are about hiding complexity rather than exposing it.

The first is to provide web developers a uniform JavaScript API for accessing browser-provided language models of varying capabilities. The second is to encapsulate model management and execution details as much as possible, with downloads, updates, templating and parsing named explicitly. The third is to guide web developers to gracefully handle failure cases, and the example given is no browser-provided model being available. The fourth is to develop formal implementation guidelines and definitions, covering initial on-device models and possible cloud services.

The non-goals are stated with the same clarity, and the first one is a real design decision rather than a disclaimer. The proposal does not intend to force every browser to ship or expose a language model, and it notes that not all devices will be capable of storing or running one. A conforming implementation could always signal that no language model is available, and it may also be viable to implement the API entirely by using cloud services instead of on-device models.

The second non-goal is a refusal to make promises about model behaviour. There are no guarantees of language model quality, stability, or interoperability between browsers, and in particular no guarantee that the models exposed are particularly good at any given use case. The README places these in the category of quality-of-implementation issues and compares the situation to the shape detection API.

For an implementer, that is the useful part. The failure path is a documented state rather than an exception, and the model quality question is deliberately left to the browser vendor.

The goals that are not settled: data residency and model identity

Two further goals are listed as potential, with the wording that they are not yet certain of, and they are the two a privacy conscious team will care about most.

The first is letting web developers know or control whether language model interactions are done on-device or using cloud services. The stated purpose is to guarantee that any user data fed into the API does not leave the device, which the document says can be important for privacy purposes, and to allow developers to request on-device-only language models in case a browser offers both varieties.

The second is letting developers know some identifier for the language model in use, separate from the browser version, so they can allowlist or blocklist specific models to maintain a desired level of quality, or restrict certain use cases to a specific model.

Both are explicitly flagged as potentially posing challenges to interoperability, and the README says the group wants to investigate how important such functionality is to developers in order to find the right trade-off.

That is a sign of a specification being honest about its own open questions rather than a sign of a gap. It also tells implementers what is likely to be contentious in review, and it is worth noticing that both items are ones a cloud-only implementation cannot offer at all.

Sampling parameters and the renaming already under way

The experiments section records what has actually been built, and the sampling parameter design is the most concrete part.

Developers expressed the value of tuning sampling parameters for testing and optimising task-specific model behaviour, while web standards engagements highlighted the need for more interoperable API shapes across different models. The API was initially made available in extension contexts with a specific set of options and attributes. The static method LanguageModel.params() exposes default and maximum values for sampling parameters, which the README lists as:

defaultTemperature
maxTemperature
defaultTopK
maxTopK

The temperature and topK options can be given to LanguageModel.create() to control the sampling behaviour of individual sessions, and the same two values exist as attributes on session instances so a client can read the current values back.

Access to these features is limited to extension and experimental web contexts, and the README says ongoing experimentation and community engagement will explore different API shapes.

The renamed features table is the part to read before writing any code against an extension build. Features have recently been renamed, the legacy aliases are deprecated, clients should update to the new names, and the aliases will be removed from extension contexts in a future release. The table distinguishes names deprecated in extensions and removed on the web from names available in all contexts, so an implementation that works in an extension today may not work on the open web tomorrow.

How the specification is written and who decides

The repository is small, and that is what a specification source looks like. There is an index.bs file, which is the Bikeshed source that the documentation is generated from, a w3c.json file describing the group and the specification metadata, a .pr-preview.json file for previewing pull requests, a CONTRIBUTING.md, a security and privacy questionnaire, and the LICENSE.md.

The primary language being Bikeshed rather than JavaScript or Python tells you what this repository is. It is not an implementation. There is no package to install and no API to call, and the deliverable is a document that a browser vendor could implement and a web developer could target.

The governance is the Web Machine Learning Community Group, and the README states the goal plainly: to gain Working Group and implementer adoption. A Community Group is a stage in the W3C process, and the note that members are seeking feedback and support for that transition is the clearest signal of where the document sits.

The security and privacy questionnaire in the tree is the part worth a technical reader's attention. A specification that asks a browser to expose a general purpose language model to any page has obvious abuse considerations, and the questionnaire is where those questions get asked in a form that can be answered.

Where the Prompt API is the wrong approach

Three cases point elsewhere.

The first is a product that needs predictable output. A general prompt API returns text, and the developer owns the parsing, the templating and the failure handling, which means a model update on the browser side can change your product's behaviour without any change on yours. The purpose built APIs exist precisely to narrow that surface, and for a translation feature or a proofreading feature the narrower API is the better engineering choice.

The second is a team that needs a specific model. The proposal is careful to say it makes no guarantees about model quality, stability, or interoperability between browsers, and the identifier that would let you allowlist a model is listed only as a potential goal. If your feature depends on the behaviour of a particular model, an on-device browser model is the wrong dependency, and a cloud API where you pin the model version is the right one.

The third is a deployment where the browser will not have a model. The specification is explicit that not all devices will be capable of storing or running one, and a conforming implementation may always report that no model is available. Any feature built on this API therefore has to be an enhancement rather than a dependency, and the goals section says as much when it asks the specification to guide developers to handle failure gracefully.

The practical summary is that this is a proposal to watch rather than a dependency to plan around. The Chrome and Edge implementations are experimental, the API is still being renamed, and the group is still gathering support to move to a Working Group.

Editorial conclusion

Adopt the Prompt API design as a reference if you are building browser features that use a built-in model, particularly if you are deciding between a general prompt API and one of the purpose built alternatives, because the explainer sets out the trade precisely. Do not treat it as an available dependency today, since it is a proposal in active development whose implementations are experimental in Chrome and Edge. Verify three things first: how the API behaves when no model is available, because the specification is explicit that this is a conforming state rather than an error; whether you need the on-device guarantee and the model identifier that are listed as potential goals rather than settled ones; and how the sampling parameter names have changed, since the explainer records renamed features with legacy aliases deprecated and scheduled for removal from extension contexts. The repository is a Bikeshed specification source, the licence is a custom one recorded in LICENSE.md, and the last push was on 2026-10-16.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. webmachinelearning/prompt-api on GitHub