Inline semantics
em vs i, strong vs b, mark, cite, time, abbr, code vs samp vs kbd vs var — small tags that change meaning, not just looks.
Most beginners learn <b> for bold and <i> for italic, then move on. That works for sighted readers — but it leaves a lot of meaning on the table. HTML has a small zoo of inline tags whose job is not appearance but meaning: this word is emphasized, this is a citation, this is a date, this is a key the user should press.
Pick the right one and screen readers can announce it correctly, search engines pick up on it, browser extensions can transform it ("convert all <time> to my local timezone"). Pick <i> for everything italic and you get italic text — and nothing else.
em vs i, strong vs b
These four look the same in the browser by default — em and i render italic, strong and b render bold. The difference is whether they carry meaning.
<em>— emphasis. The word matters; if you read the sentence aloud, your voice would lift on it.<i>— italic for a different reason — a foreign phrase, a ship name, a thought, a technical term on first introduction.<strong>— strong importance. A warning, a key piece of information.<b>— bold for a different reason — a keyword in a paragraph, a product name, anything that should stand out visually but is not "important" in the sentence sense.
<p>I told you to <em>not</em> press that button.</p> <p>The latin name is <i>Saccharomyces cerevisiae</i>.</p> <p><strong>Warning:</strong> this operation cannot be undone.</p> <p>Try the <b>extra-spicy</b> version if you can handle the heat.</p>
A screen reader can change its tone for <em> and <strong> — for emphasis, it lifts the voice; for strong, it lowers and slows. It does not change tone for <i> and <b>, because those are styling choices for sighted readers, not changes in meaning.
The rule of thumb: if reading the sentence aloud differently would change what it means, use <em> or <strong>. Otherwise reach for <i> or <b>. And if you only want italic for a design reason and the meaning does not matter, plain CSS (font-style: italic) is fine — no tag needed.
In doubt, default to <em> and <strong> for words that change meaning when emphasized. Save <i> and <b> for the narrower cases (foreign words, product names). Most prose lands closer to em/strong than to i/b.
<p>The setting is <b>not</b> saved until you click Apply.</p>. A reviewer suggests changing <b> to <strong>. Are they right?mark, the highlighter
<mark> is the yellow-highlighter tag. Its job is to mark text as relevant to the current context — the search query the user typed, the term they hovered, the change in a diff. It does not say "this is important always"; it says "this is important right now".
<p>You searched for: <em>sourdough</em></p> <p>Our wild-yeast <mark>sourdough</mark> loaf returns next Friday.</p>
The browser's default style for <mark> is a yellow background. You can restyle it however you want; the meaning ("highlighted in this context") is what tools key off.
A screen reader announces marked text — some say "highlighted, sourdough, end highlighted". That helps the user notice why a result was returned.
cite, time, abbr
Three more inline tags that look small and pull a lot of weight when you use them.
<cite> wraps the title of a creative work — a book, film, song, painting, paper. Not the author. Browsers italicize it by default.
<p>The idea comes from <cite>Don't Make Me Think</cite> by Steve Krug.</p>
<time> wraps a date or time. The visible text is human-readable; the datetime attribute is the machine-readable form. Search engines, calendar plugins, and "convert to my timezone" extensions all read the datetime.
<p>Posted on <time datetime="2026-04-29">April 29, 2026</time>.</p> <p>Doors open at <time datetime="19:30">7:30 pm</time>.</p>
The visible text can be casual ("yesterday", "next Friday"). The datetime value is in ISO 8601 format — YYYY-MM-DD for dates, HH:MM for times.
<abbr> wraps an abbreviation or acronym. The title attribute holds the expansion, which most browsers show as a tooltip on hover.
<p>The <abbr title="World Wide Web Consortium">W3C</abbr> publishes the HTML spec.</p>
A screen reader may announce the expansion the first time the abbreviation appears. A new reader sees "W3C" with a hover hint; a returning reader just sees "W3C".
code, samp, kbd, var
Four cousins for technical text. They all render in a monospace font by default, but they mean different things.
<code>— a fragment of computer code. A function name, a CSS property, a tag name.<samp>— sample output from a program. The thing that comes back.<kbd>— keyboard input the user should press. Specific keys.<var>— a variable in math or code text — a placeholder for a real value.
<p>Run <code>npm install</code> and you'll see <samp>added 312 packages</samp>.</p> <p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save.</p> <p>The function takes <var>x</var> and <var>y</var> as inputs.</p>
For a single line, you might think these distinctions are silly. But on a docs page with hundreds of code references, the consistency starts paying off. CSS can target each independently — kbd keys can render with a key-cap shape, samp output can sit in a console-style box, code can be inline-tinted, var can be italic. None of that requires a single class.
<!-- broken: a key combo all rolled into one kbd is unclear --> <p>Press <kbd>Ctrl + S</kbd> to save.</p>
The fix is to wrap each key separately. Not because the page looks worse — the page looks the same — but because a screen reader can now announce "press Control plus S" instead of treating it as one indivisible chunk.
<p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save.</p>
<code> is for inline references. For a multi-line code block, wrap a <pre> around a <code>: <pre><code>...</code></pre>. The <pre> preserves whitespace; the <code> says "this is code". Together they are the standard pattern for code samples.
Pulling it together
A short paragraph from a real-feeling docs page, marked up properly:
<p> The <abbr title="Document Object Model">DOM</abbr> is the in-memory tree the browser builds from your HTML. To inspect it, open DevTools (<kbd>F12</kbd> on Windows, <kbd>Cmd</kbd> + <kbd>Opt</kbd> + <kbd>I</kbd> on Mac) and switch to the <em>Elements</em> tab. The example below uses <code>document.querySelector</code> to grab the first heading. </p>
That paragraph reads identically to a sighted user as one with <b> and <i> everywhere. To a screen-reader user, it is a different document — keys are spoken as keys, the abbreviation is expanded, the emphasis is read with a tone change. To search engines, the technical terms are flagged. To future-you maintaining the page, the intent is in the markup.
The cost is one or two extra characters per word. The benefit is a page that means what it looks like.
<p>The event is on <b>April 29</b>.</p>. A user installs a browser extension that converts dates to their local timezone. Will the extension work?fetch(url), which returns a Promise". Which inline tags are doing meaningful work here?