Chrome Is Testing a Spell-Check API That Could Make Web Apps Feel More Native
A red squiggle looks trivial until it appears under every product name, medical term or stock ticker in a professional web app. Then it becomes something more damaging: a steady signal that the software does not understand its own subject.
Chrome is now testing a narrowly focused browser API designed to fix that problem. It will not transform web distribution or unlock a new install flow. But for text-heavy web apps, it could remove one of those small, persistent differences that still makes browser software feel less finished than a dedicated desktop application.
What Chrome has opened for testing
On August 4, Chromium marked the Spell Check Custom Dictionary API as ready for developer testing. The feature remains experimental; it has not shipped as a stable, cross-browser web capability.
The proposal gives a secure web document a document.spellCheckCustomDictionary object. An application can pass domain-specific words to addWords() and later retract them with removeWords(). If the browser’s normal spell checker would flag one of those words, the document’s custom list can suppress that false positive.
The important word is document. The vocabulary is transient and scoped to the current document. Closing the tab or navigating to another document discards it. The API does not write into the user’s permanent browser or operating-system dictionary, and an embedded frame receives a separate dictionary for its own document.
That limited scope is deliberate. A financial dashboard can recognize tickers and company names without teaching every other application on the device that those strings are universally correct. A single-page app can also remove terms when its active workspace changes, preventing an all-session vocabulary from growing without control.
The feature is equally clear about what it does not do. It does not provide spelling suggestions, autocorrect, AI proofreading or access to the contents of the user’s existing dictionary. It only adds a local suppression layer over the browser’s current spell-checking pipeline.
Why a red underline is a product problem
General-purpose dictionaries work well for ordinary prose and predictably struggle with specialized software. Finance products contain symbols and company-specific terminology. Healthcare tools contain drug names and clinical language. Developer products contain package names and technical vocabulary. Games and publishing platforms may have entire fictional lexicons.
When correct terms are repeatedly marked as errors, the interface creates avoidable friction. Users pause to inspect non-problems, genuine mistakes become harder to notice, and the product appears less aware of its own data. That matters most in applications where accuracy is part of the value proposition.
Native applications can often integrate more directly with platform spell-checking systems or provide their own text infrastructure. Web apps have had fewer standardized ways to tell the browser, for this document only, that a known term is valid. Chrome’s experiment targets that gap without asking users to maintain a personal dictionary for every specialized product they use.
For installable web apps, this is precisely the kind of improvement that compounds. Installation creates an expectation of application-quality behavior: focused windows, durable state, offline resilience and polished input. A standalone window does not hide a weak editing experience. In fact, removing the surrounding browser interface can make inconsistencies inside the app more noticeable.
Who should test it
- Text-heavy SaaS teams building document editors, knowledge systems, customer-support tools or content-management products.
- Finance, healthcare and scientific products whose legitimate terminology routinely conflicts with general dictionaries.
- Developer-tool makers handling package names, APIs, commands and other strings that ordinary spell checkers misclassify.
- PWA teams with offline workflows that can bundle or cache a relevant vocabulary and rebuild the transient dictionary when a document starts.
The best early tests are not simply demonstrations that an underline disappears. Teams should measure whether a carefully controlled vocabulary reduces false positives without hiding genuine errors. Single-page applications should also test dictionary cleanup as users move between projects, tenants or workspaces.
Production code will still need feature detection and a harmless fallback. Because the capability is experimental, an app cannot assume that a user’s browser exposes it—or that the final API will retain its current shape.
The privacy design is as important as the UX
A dictionary API could become a fingerprinting surface if pages were allowed to inspect words that a person had saved elsewhere. The current proposal avoids that obvious trap by exposing add and remove operations without providing methods to enumerate, query or measure the browser’s underlying dictionary.
The custom vocabulary stays with the document, does not require a network request and does not modify system-wide spell-checking data. Those boundaries make the proposal useful without turning personal language habits into a broadly readable browser signal.
There is still work to watch. The technical explainer acknowledges a possible highlight-related timing side channel around spelling and grammar error rendering. It also leaves resource limits, such as maximum word counts and word lengths, to browser implementations for now. Those details will matter if the feature advances toward stable release.
What actually changes for web apps
This API does not make a site installable, add it to an app store or improve service-worker caching. Its value sits higher in the experience stack: it lets a web product supply context that the browser’s generic language tools do not possess.
That is still strategically relevant. The gap between a website and an application is increasingly defined by dozens of small behaviors rather than one dramatic missing capability. File handling, notifications, window controls, reliable offline state and intelligent text input all contribute to whether users trust an installed web app as daily software.
A custom dictionary will not decide a platform strategy by itself. For products built around writing, reviewing or entering specialized information, however, it could remove a visible source of friction without replacing the browser’s spell checker or exporting user data to another service.
What IndApp watches next
The immediate milestone is not adoption; it is evidence. IndApp will watch for:
- A formal Chromium shipping proposal and a stable release target.
- Published positions from WebKit and Mozilla, whose review requests remain open.
- Resolution of the W3C Technical Architecture Group’s concerns and the documented highlight side channel.
- Clear interoperable limits, lifecycle behavior and test coverage across operating systems.
We will also watch whether the idea grows beyond whole-document spell checking. The proposal discusses possible future subtree-scoped dictionaries, a declarative vocabulary link and coordination with speech or proofreading tools. None of those extensions is promised.
For now, the signal is smaller but credible: browser makers are treating contextual text input as part of the web application platform. If the experiment survives privacy review and gains cross-browser support, one of the web’s most familiar signs of roughness may finally become something app developers can fix.
Further reading
Recent news
