Difference between strong and b tags in HTML

HTML & CSS~4 min read

 and  both make text bold by default, but only  tells the browser, and everything listening to it, that the text actually matters.

Theory

TL;DR

 = marker highlight on paper: changes how it looks, says nothing about why
 = starred email: changes how it looks AND flags it as important
Screen readers stress  content; they read  flat, like any other text
Both get font-weight: bold from user agent stylesheets, so visually they look identical
Decision rule: meaningful emphasis → . Pure style → CSS font-weight: bold

Quick example

html

<p>Regular text, then <b>bold but no meaning</b>.</p>
<!-- Screen reader: reads "bold but no meaning" flat, no stress -->

<p>Regular text, then <strong>important bold</strong>.</p>
<!-- Screen reader: stresses "important bold" with raised pitch -->

Open this in a browser with NVDA or VoiceOver and you hear the difference instantly. Visually? Identical.

 is a presentational tag. It puts bold in the render tree and stops there.  goes further: browsers map it to an importance role in the accessibility tree, which AT APIs like MSAA and IAccessible2 pick up. That is why screen readers announce  content with stress or a prefix like "important", while  gets nothing extra.

When to use

Product name or UI label where bold is a pure design choice → CSS font-weight: bold, or  as a last resort
Warning, deadline, or error message the reader must not miss → 
Legacy code that needs bold for appearance only → add a CSS class, avoid both tags
Accessibility or SEO is a priority → always , never

Comparison table

Aspect	`<b>`	`<strong>`
Default style	Bold	Bold
Semantics	None (presentational)	Importance
Screen readers	Reads flat	Announces with stress
SEO impact	Neutral	Signals keyword relevance
Accessibility tree	Not mapped	Mapped to importance role
When to use	Rare; visual-only labels	Warnings, key facts, articles

How the browser handles this

Both tags get font-weight: bold from the browser's built-in stylesheet, which is why they look the same without custom CSS. The split happens in the accessibility tree:  gets an importance role that assistive technologies read from the OS-level accessibility API;  stays in the render tree only. One CSS rule (strong { font-weight: normal; }) strips the visual bold from  but leaves the semantic role intact. Screen readers still stress it.

Common mistakes

Using  for warnings or critical text:

html

<!-- Wrong: screen reader reads this flat -->
<p>Warning: <b>High voltage area</b>. Do not enter.</p>

<!-- Right: screen reader stresses the warning -->
<p>Warning: <strong>High voltage area</strong>. Do not enter.</p>

Assuming  always means bold styling:

css

/* This strips visual bold but NOT the semantics */
strong { font-weight: normal; }

If a custom theme resets  visually, AT still flags it as important. Tie style to a CSS class, not to the tag itself.

Nesting  inside  carelessly:

html

<strong>Critical: <b>check this</b> before deploy.</strong>

The outer  applies its importance role to all content inside, including the  part. The  only adds a visual hook. This is valid HTML, but flattening it to one  with CSS control is cleaner and clearer in intent.

Real-world usage

MDN Web Docs uses  for warnings and deprecated API notices throughout its guides
React docs wrap required prop names in  to signal importance, not just styling
WordPress Gutenberg defaults to  when you press the bold button in the editor toolbar
Bootstrap documentation recommends  over  in its typography section

Follow-up questions

Q: Can CSS make  and  completely identical?
A: Visually, yes. But semantically, no. The accessibility tree still marks  as important and screen readers still react to it, regardless of how it looks on screen.

Q: Does Google treat  differently from  for SEO?
A: Google has confirmed that  carries weight as a keyword relevance signal.  is treated as neutral styling. The difference matters for content with keywords you want to rank for.

Q: Is  still valid in HTML5?
A: Yes. HTML5 keeps  and redefines it as a tag for text that is "stylistically different" without conveying importance. It is valid, but WCAG 4.1.2 pushes toward semantic alternatives wherever meaning is involved.

Q: How does  behave inside an aria-hidden container?
A: The semantic role gets suppressed and assistive technology skips the content entirely. If you place  inside a container with aria-hidden="true", screen readers will not announce it regardless of the tag.

Examples

Basic: visual vs semantic bold

html

<!DOCTYPE html>
<html lang="en">
<body>
  <p>Save your work often. <b>Autosave</b> is disabled by default.</p>
  <!-- "Autosave" looks bold, screen reader reads it flat -->

  <p>Save your work often. <strong>Autosave is disabled</strong> by default.</p>
  <!-- Screen reader stresses "Autosave is disabled" -->
</body>
</html>

 here just makes the word stand out visually.  tells the user, and every tool reading the page, that this is something to pay attention to.

Intermediate: React component with semantic emphasis

jsx

// OrderSummary.jsx
function OrderSummary({ productName, deadline }) {
  return (
    <article>
      <h2>Order Summary</h2>
      <p>
        You selected <b>{productName}</b>.
        {/* Visual label only - no semantic weight needed */}
      </p>
      <p>
        Complete payment by <strong>{deadline}</strong> to avoid cancellation.
        {/* Deadline is important - screen reader stresses it */}
      </p>
    </article>
  );
}

 on the product name is a design choice.  on the deadline is a signal: if a user navigates by screen reader, they should not miss that date.

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.

Finished reading?