#1146: Incubation: Proofreader API

Visit on Github

Opened Sep 4, 2025

I'm requesting an early TAG design review of the writing assistance APIs.

Proofreading is the process of examining a text carefully to find and correct errors such as grammar, spelling, and punctuation to generate an error-free text before it is published or shared. Browsers and operating systems are increasingly offering proofreading capability to help their users compose (examples: Oodles of improvements to Chrome's Spell Checking, Use Writing Tools with Apple Intelligence on Mac). Web applications can also benefit from such proofreading capability backed by language models for a variety of use cases.

We're proposing an API that uses language models to give web developers high-level functionalities for proofreading. Specifically:

  1. Error Correction: Correct input text by the user
  2. Error Labeling: For each correction made to each error in the input text, label the error type (e.g. spelling, punctuation, etc.)
  3. Error Explanation: Annotates each error with a plain language explanation

Explainer

https://github.com/webmachinelearning/proofreader-api/blob/main/README.md

The explainer

Where and by whom is the work is being done?

Feedback so far

  • Multi-stakeholder feedback:
    • Chromium comments: We are excited to start trialing this API with developers through origin trials and behind-a-flag experiments.
    • Mozilla comments:
    • WebKit comments:
    • Web developers:
      • Public feedback on https://github.com/webmachinelearning/proofreader-api/issues was mixed. To summarize, some themes we saw include: asking for more capabilities (e.g. integrating custom dictionaries; adding confidence score to correction output); desire to make sure the API performs efficiently in real-world use cases like proofreading during active editing of the text.

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1146

Discussions

Log in to see TAG-private discussions.

Discussed Oct 13, 2025 (See Github)

Christian: Didn’t have a look yet. Matthew: Would need a little bit more time.

Discussed Oct 20, 2025 (See Github)

Christian is not here...

Matthew: I need a bit more time.

Ehsan: Also still reading it. Will post it hopefully next week.

Discussed Oct 27, 2025 (See Github)

Matthew: We are not the experts on these sorts of tools, but we might know people who are. So much fail in the UK.

Christian: Not a domain expert, but it looks fine. Check with domain experts. Shares a lot of features with other AI-related APIs, so it is somewhat blocked by those discussions.

Hadley: i18n we have some choices to make. We could ask the i18n folks to look into this. They can be helpful, but it is a big ask of them. Another option is we could go to a former TAG member with expertise if they want to help out. No one comes to mind. Sangwhan has an interest in i18n because we were messing with his daily life, more than a professional interest. We could say to the group what you said and leave it at that.

Christian: I would prefer to wait on the Prompt API response. A lot of the feedback there applies to Proofreading, especially the model download/initialization part. We should be open about that.

Hadley: Pending external feedback?

Christian: fine.

Matthew wanted to say something about this as well, but he was having connectivity issues.

Matthew: I put in slack that Ehsan has a comment coming, but that's compatible with the above resolution.

Comment by @christianliebel Oct 30, 2025 (See Github)

@QueenieZqq Thanks for your proposal. As it shares parts of its API surface with the Prompt API, we want to finalize the Prompt API review (https://github.com/w3ctag/design-reviews/issues/1093) before proceeding. We will postpone the review of this API until that review is complete.

Discussed Jan 26, 2026 (See Github)

Christian: This is unblocked now because it was depending on the Prompt API review. We concluded that review with lack of consensus. The question is what do we want to do with this one? We discussed before and said we're not experts in that domain. We could continue with that approach, or bring it bak for more discussion.

Lola: What was the reason on Prompt API?

Christian: It was regarding the issues around downloading the model.

Hadley: Another option is to find an expert we know, maybe a former TAG member, or someome who is an expert.

Lola, Christian: ACK.

Ehsan: The download issue was previously discussed in TAG and we had given positive feedback - in the Translation API.

Christian: That's true and also shares API shape with Prompt API. I might give that a read and come back next week.

Ehsan: I have a review for proofreader but haven't shared it yet as it was on pause, will share it by end of week (private thread).

Lola: I think the API was Web Speech (Translation was 2024). Jeffrey praised that they had removed the cloud only requirement.

Christian: We can review your text, and also ask a domain expert, or former TAG member.

Discussed Feb 2, 2026 (See Github)

Christian: I had a look this morning. We said satisifed with concerns to translator API. Also has a model download system, which we also criticised in the Prompt API review, where we did not reach consensus. I was also leaning to 'satisfied with concerns' but then saw Marcos and Jeffrey's comments from November and they may be right that proofread is implemented on so many levels already, e.g. UA, OS, UA Extensions (e.g. Grammarly). So: Do we actually need this? That's the first question we have before diving into a review.

... I prepared a comment, Ehsan wants to add something to it. Want to check with Jeffrey that this next step is what you wanted to do back in November.

Jeffrey: I'm a little unconfortable with them doing this on top of Prompt, as prompt is more general, this is finely tuned. This seems more useful than some of the other AI APIs - I have more confidence in a proofreading use of LLMs than others. Asking what are the use cases makes a lot of sense.

Christian: Removed the sentence about Prompt API. Let's wait for Ehsan, and then post.

Comment by @christianliebel Feb 5, 2026 (See Github)

@QueenieZqq Thank you for this proposal. During our initial discussions, this question came up: What is the core justification for a platform-level JavaScript API for proofreading?

As mentioned in your design review request and your explainer, proofreading capabilities already exist across several layers:

  1. User Agents: Most browsers provide built-in spellcheck and basic grammar tools.
  2. Extensions: Services like Grammarly offer even more sophisticated corrections.
  3. Operating Systems: OS-level features (e.g., Apple’s Writing Tools) provide AI-powered proofreading across all apps.

While we acknowledge that these existing solutions do not typically expose explanations or corrections to site authors, and there are certainly apps and users that would benefit from this kind of API, we wonder if the use case is common enough to justify a platform-level API, given the many alternatives that already exist.

We share your concerns regarding the user experience. If the site, an extension, the user agent, and the OS all simultaneously attempt to provide proofreading UI, the resulting interaction would be cluttered or distracting for the user. The explainer currently leaves this potential conflict as an open question.

Please note that this is not yet a formal review. We wanted to hear your thoughts on the core justification for this API before conducting it.