The HTML spellcheck attribute and browser spell checking, explained
Every major browser ships a spell checker, and one HTML attribute controls whether it underlines words in your form fields. Here is how it behaves, and when you should switch it off.
The attribute
spellcheck is a global HTML attribute, defined in the HTML Living Standard's section on spelling and grammar checking. It takes "true" or "false":
<textarea spellcheck="true"></textarea>
<input type="text" name="username" spellcheck="false">
<div contenteditable="true" spellcheck="true">Edit me</div>
A few points that often surprise developers:
- It is an enumerated attribute, not a boolean one. Writing
spellcheckwith no value, orspellcheck="", meanstrue. To disable it you must writespellcheck="false"; simply omitting the attribute leaves the browser's default in place. - It is inherited. If an element has no value, it takes the setting of its nearest ancestor that has one. Putting
spellcheck="false"on a<form>turns it off for the fields inside, unless a field sets its own value. - It is a hint. The specification lets browsers decide what checking means and lets users override it. A user who has disabled spell checking in their browser settings will see no underlines whatever the page says.
- Defaults differ. Browsers generally check
<textarea>and editable content by default. For single-line<input type="text">, behaviour varies: Firefox, for instance, by default checks only multi-line fields. If you want a single-line field checked everywhere, setspellcheck="true"explicitly.
From JavaScript, the element.spellcheck property reflects the attribute as a boolean. The MDN reference for spellcheck tracks current browser support.
Choosing the dictionary with lang
Which language the browser checks against depends on the browser and the user's settings, but the lang attribute is the standard way for a page to say what language a field contains. A form for British readers can declare it on the root element or on individual fields:
<html lang="en-GB">
...
<textarea lang="fr"></textarea> <!-- a field meant for French text -->
Browsers can only use dictionaries the user has installed or enabled, and some ignore lang in favour of the user's chosen languages or automatic detection. Still, declaring it correctly costs nothing, helps screen readers pronounce text properly, and is required for accessibility under WCAG success criterion 3.1.1, Language of Page.
Related attributes
autocapitalizecontrols automatic capitalization on virtual keyboards:off/none,sentences,words,characters. It has no effect on physical keyboards.autocorrect(on/off) controls automatic correction while typing. It began as a non-standard Safari attribute and support elsewhere is limited, so check MDN before relying on it.autocompleteis unrelated to spelling but often set alongside: it tells the browser what kind of data a field holds (email,username,one-time-code), so password managers and autofill work properly.
For a username field the common combination is:
<input type="text" name="username" autocomplete="username"
autocapitalize="none" spellcheck="false">
When to turn spell checking off
- Codes, identifiers and handles: usernames, product codes, coupon codes, hostnames, file paths. Red underlines on correct input erode trust.
- Code editors and fields for markup, where almost every token would be flagged.
- Sensitive fields. See the next section.
- Your own checker. If the page provides its own spell-checking interface, as the Letterbench spell checker does, disable the browser's on that field so users do not see two sets of underlines that disagree.
Leave it on for anything people write in natural language: comments, messages, descriptions, support requests.
Privacy: local versus cloud checking
By default, browser spell checkers compare words against dictionaries stored on the device. Some browsers also offer an optional enhanced mode that sends text to a cloud service for better, context-aware suggestions. Google Chrome's settings, for example, describe "Enhanced spell check" as using the same spell checker as Google Search, with text typed in the browser sent to Google; Microsoft Edge has offered a similar cloud-based Microsoft Editor feature.
In 2022, researchers at the security company otto-js publicized what they called "spell-jacking": with these enhanced features enabled, the contents of form fields, including passwords when a "show password" button revealed them as plain text, could be sent to the provider's servers. The widely reported mitigation for site owners was simple: add spellcheck="false" to fields containing passwords, personal data or other sensitive information. Browsers do not spell-check type="password" fields, but a "show password" toggle that switches the type to text changes that.
<input type="password" id="pw" autocomplete="current-password" spellcheck="false">
<button type="button" onclick="pw.type = pw.type === 'password' ? 'text' : 'password'">
Show password
</button>
Whether a feature like this sends text anywhere is controlled by the user's browser settings, not the page; the attribute is your way of opting sensitive fields out.
Styling and limitations
The browser draws the underline itself, so pages cannot restyle it in most browsers. The CSS pseudo-elements ::spelling-error and ::grammar-error are specified for this purpose, but support is limited; check before relying on them. Nor can a page read the browser's suggestions or the list of flagged words: the browser's checker is deliberately sealed off from scripts. If you need to show flagged words, counts or custom suggestions, you need your own checker, which is exactly why the Letterbench tool implements one in JavaScript; its documentation shows how.