Proofreader API

concepts

1. Proofread

   On-device proofreader — grammar and spelling issues with suggestion ranges. Runs against the same on-device model family as Summarizer / Translator / Prompt.

2. Compose Overlay

   Email-style compose field with a clickable strike-through overlay — accept all replaces the draft with the corrected version. Models the polish-email-drafting use case the explainer lists first.

3. Chat Realtime

   Single Proofreader instance reused across keystrokes, debounced. Latency-per-call is shown so you can see how much budget you have inside a sub-200ms chat input loop.

4. Writing Quality Dashboard

   Three text panels — casual chat, formal report, technical docs — each proofread on demand. A quality score meter tracks grammar, spelling, and style issues. Diff overlay highlights changes; accept-all rewrites the draft. Shows feature-detect fallback when the on-device model isn't available.

why it shipped

Browsers and operating systems are increasingly offering proofreading capability to help their users compose. By exposing this built-in model, we allow web applications to gain access to proofreading capability with the help of a language model, while avoiding every website needing to download their own multi-gigabyte language model, or sending input text to third-party APIs. The proofreader API in particular exposes a high-level API for interfacing with a language model in order to proofread inputs for a variety of use cases [1], with three specific proofreading functionalities: error correct

references

• ChromeStatus entry
• Spec