← Back to release summary

Spell check custom dictionary API

Category
JavaScript
Type
New or changed feature
Status
Proposed (Chrome Proposed)
Intent stage
None

WPT details: There are no WPTs yet. The tests for the API surface are currently in Chromium's wpt_internal, which is Chromium-only. We plan to upstream the API-surface tests to WPT alongside the spec PR. The API's only effect is whether a word gets a spelling marker. Spelling markers depend on the platform spellchecker and aren't observable from script, so there's no portable way for a WPT to assert them. Existing spellcheck features (e.g. the spellcheck attribute) have the same limitation. Chromium-side coverage of that effect: - Web tests that read spelling markers through the mock spellchecker. - Blink unit tests for input validation and word limits. - components/spellcheck for applying the filter to the hybrid, platform and spelling-service results, lifetime across navigation, and the UMA metric. - Manual tests in wpt_internal/spell-check-custom-dictionary/ for checking the squiggles visually on each platform, including WebView.

Summary

Adds document.spellCheckCustomDictionary, which lets a page add words to and remove words from a per-document dictionary that the browser's spell checker consults alongside its built-in dictionaries. Matching words are no longer flagged as misspelled in that document, so sites with domain-specific vocabulary, such as product names, technical terms or proper nouns, can suppress false positives without asking users to edit their browser dictionary. The words last only for the document's lifetime and cannot be read back.

Motivation

Spell checkers routinely flag words that are correct within a particular site but unknown to general dictionaries. Examples include: - A Pokémon wiki containing names like Pikachu or Charmander. - A financial analysis dashboard referencing company‑specific product names or tickers. - A medical or scientific tool using specialized terminology. False positives in these contexts are distracting, misleading, and erode user trust. While browsers allow users to add custom words via browser settings panel, there is currently no way for pages to provide a custom dictionary programmatically that applies only within their own context in order to reduce those false positives. Authors need a way to treat domain‑specific words as “known” without requiring user intervention.

Standards & signals

Ecosystem

Docs: https://github.com/Igalia/explainers/tree/main/spell-check-dictionary https://docs.google.com/document/d/1ND1a1Z4i6kXMHqMwEyRkHSj5VVTWgX5Ya0aNLgVQYGw/edit?tab=t.0#heading=h.kmfizh6cwyy4

Samples: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/spell-check-custom-dictionary/add-remove-words-manual.html

Explainers: https://github.com/Igalia/explainers/tree/main/spell-check-dictionary

View on chromestatus.com