HTML spellcheck Attribute

Introduction

The spellcheck attribute lets you control whether the browser should check spelling in editable text. When enabled, misspelled words are often marked with a red underline so users can fix them before submitting a form or publishing content.

spellcheck is a global attribute, but it only affects elements where the user can type or edit text—such as <textarea>, text-like <input> fields, and elements with contenteditable. It is a hint to the browser; users can still override spell checking in their browser or OS settings.

What You’ll Learn

Purpose of spellcheck

The primary purpose of the spellcheck attribute is to tell the browser whether to perform spell checking on text inside an editable element. Most browsers enable spell checking by default on fields like <textarea>, but you can turn it off when underlines would be unhelpful—for example on code editors, product SKUs, or usernames that are not dictionary words.

Spell checking improves writing quality in comments, bios, and message boxes. It is not a substitute for server-side validation or grammar tools; it is a lightweight, built-in UX feature that runs locally in the user’s browser.

📝 Syntax

Add spellcheck to any editable element with true or false:

<!-- Spell checking on (common for textarea) -->
<textarea spellcheck="true"></textarea>

<!-- Spell checking off (usernames, code) -->
<input type="text" spellcheck="false">

<!-- contenteditable region -->
<div contenteditable="true" spellcheck="true">Edit me</div>

Syntax Rules

• Valid values: true or false (boolean attribute semantics).
• If omitted, the browser uses its default for that element (often enabled on textarea).
• Only affects editable elements; it has no effect on plain static text nodes.
• Can be inherited: child editable nodes may inherit the parent’s spell-check state.
• In JavaScript, use the boolean property element.spellcheck, not a string.
• Does not validate grammar or block form submission—it only marks possible typos visually.

💎 Values

The spellcheck attribute accepts two enumerated values:

• spellcheck="true" — Ask the browser to check spelling in this editable element.
• spellcheck="false" — Ask the browser not to check spelling (no red underlines from spell check).
• Omitted — Browser default applies; typically on for textarea and many contenteditable regions.

<textarea spellcheck="true">Comment with spell help</textarea>

<input type="text" spellcheck="false" name="handle">

<div contenteditable="true" spellcheck="false">
  Code snippet: const foo = bar;
</div>

Applicable Elements

spellcheck vs validation vs autocorrect

Examples Gallery

contenteditable with spellcheck on vs off, JavaScript toggle, and form fields (textarea / input).

<div contenteditable="true" spellcheck="true">
  <p>Editable content with spell-checking enabled.</p>
</div>

<div contenteditable="true" spellcheck="false">
  <p>Editable content with spell-checking disabled.</p>
</div>

<div id="dynamicElement" contenteditable="true" spellcheck="true">
  Type here...
</div>
<button type="button" id="toggleBtn">Toggle spellcheck</button>

<script>
  var el = document.getElementById("dynamicElement");
  document.getElementById("toggleBtn").addEventListener("click", function () {
    el.spellcheck = !el.spellcheck;
  });
</script>

<label for="bio">Bio:</label>
<textarea id="bio" spellcheck="true"></textarea>

<label for="username">Username:</label>
<input type="text" id="username" spellcheck="false">

♿ Accessibility

• Do not rely on color alone — Red underlines help sighted users; screen readers may not announce them. Provide clear labels and error messages for required content.
• Label editable fields — Associate <label> with textarea and input so users know what to type.
• Disable for assistive tech conflicts — In custom rich-text widgets, test with keyboard and screen readers when toggling spellcheck.
• Language attribute — Set lang on the page or field so the browser picks the correct dictionary.
• Respect user preferences — Users may disable spell check globally; your UI should remain usable either way.

💡 Best Practices