Skip to content

Text elements

docs.scrimba.com

Most of what a visitor reads on a page is plain written content: titles, paragraphs, a bolded warning, a quoted line, a snippet of code. HTML has a specific element for each of these jobs, and choosing the right one does more than change how the text looks. It tells the browser, search engines, and assistive tools what each piece of text actually is.

Headings and hierarchy

HTML gives you six sizes of heading, from <h1> down to <h6>. A heading is a title for the page or for a section of it. <h1> is the main title, the big one at the top. <h2> labels a major section, <h3> a subsection inside that, and so on down to <h6>.

Think of a printed book. The title on the cover is the <h1>. Each chapter title is an <h2>. The headings inside a chapter are <h3>. You use the levels to show what belongs under what.

One thing to hold on to from the start: do not pick a heading because it makes text the size you want. <h1> happens to look big, but its job is to say "this is the main title", not "make this large". If you want big text somewhere, that is a job for CSS later.

The six heading elements, <h1> through <h6>, describe a document's hierarchy: which parts are sections and which are subsections. The number is the rank, not a size. <h1> is the top of the outline, <h2> sits under it, <h3> under that.

The rule to build in early is to nest them in order and not skip a level. A section headed <h2> should contain <h3> subsections, not jump straight to <h4>. Skipping levels to reach a smaller default size is the classic mistake, and it is the wrong tool: if you want a heading to look a certain way, style it with CSS, and keep the number reserved for its rank in the structure.

The heading elements define the document's outline: the ordered, ranked structure of its sections, the same way a table of contents nests topics under topics. Three production rules follow from that, and all three are about accessibility and search rather than appearance.

First, use one <h1> per page, the true title of that page's content. It is the top of the outline, and having exactly one gives every tool a single unambiguous anchor for what the page is about.

Second, do not skip levels going down. A screen reader (software that reads a page aloud for people who cannot see it) lets its user pull up a list of every heading and jump between them, the way a sighted reader skims for the section they want. A jump from <h2> to <h4> reads as a missing level in that list, and the navigation stops making sense.

Third, the ranks are semantic, never sizes. Search engines read the heading structure to understand how a page is organised, so an <h3> chosen because its default size looked right, rather than because it is actually a third-level section, quietly misinforms both the crawler and the screen reader. Set size in CSS; let the number carry the meaning.

html
<h1>Sourdough for beginners</h1>

<h2>Building a starter</h2>
<p>A starter is a living culture of flour and water.</p>

<h3>Day one to three</h3>
<p>Mix equal weights of flour and water, then wait.</p>

<h2>Baking your first loaf</h2>
<p>Once the starter is active, you are ready to bake.</p>

One <h1> names the whole page. Two <h2> headings mark the major sections, and the <h3> sits neatly inside the first of them. Read the heading numbers on their own and you can see the shape of the article without reading a word of the body.

JunoHeadings and hierarchy Six headings, <h1> down to <h6>, and <h1> is the one main title at the top. The rest label your sections and subsections. The trap that got me early: don't grab a heading just because it looks big, that is what CSS is for. The number is about what the thing is, not its size.
JunoHeadings and hierarchy Headings rank your content, they don't size it. Nest them in order and don't skip a level to land on a smaller default, that is the one that trips people up. Need a heading to look a certain way? Style it in CSS and leave the number to describe the structure.
JunoHeadings and hierarchy One <h1> per page, no skipped levels going down, and never pick a rank for its size. Screen reader users jump between headings like a table of contents, and search engines read the same outline, so a heading chosen for looks misleads both. Keep the number semantic and push appearance into CSS.

Paragraphs and line breaks

A block of ordinary text goes in a paragraph, the <p> element. Wrap each paragraph in its own <p>...</p> and the browser gives it a little space above and below, so paragraphs sit apart the way they do in a book.

html
<p>Bread needs four things: flour, water, salt, and time.</p>
<p>Get those right and the rest is patience.</p>

Notice that pressing Enter in your HTML file does nothing to the page. The browser ignores the line breaks and extra spaces you type; it only cares about the tags. That is why you need <p> to separate paragraphs, rather than just typing them on different lines.

If you really need a line to break inside a paragraph, like the lines of an address or a short poem, there is a <br> element for that. It forces a single line break and nothing else.

The <p> element holds a paragraph of flowing text, and it is the default home for body content. The browser collapses any run of spaces, tabs, and newlines in your source into a single space, so the layout of your text on the page comes from the tags, not from how you format the file.

The <br> element forces a line break within a block of text. It is a void element, no closing tag, and it is right only when the break is part of the content itself: postal addresses, lines of a poem, a signature block.

html
<p>
  Nadia Rahman<br>
  14 Orchard Lane<br>
  Bristol BS1 4TR
</p>

Where <br> is wrong is as a spacing tool. Stacking <br><br> to push two paragraphs apart looks fine and is the wrong instinct: those are two paragraphs, so they are two <p> elements, and the gap between them is presentation, which belongs in CSS. Reaching for <br> to create space mixes structure and style, the exact habit worth breaking early.

<p> is a block-level element, meaning it starts on a new line and takes up the full width available, stacking vertically with the paragraphs around it. It is the correct container for a run of prose, and the browser applies whitespace collapsing to its contents: any sequence of spaces, tabs, and newlines in the source becomes one space in the rendered output. That is why source formatting is free to be whatever is readable to you.

<br> represents a line break that is meaningful to the content, not a layout gap. The distinction has a concrete accessibility cost. A screen reader treats a <p> boundary as the end of a paragraph and pauses accordingly, giving its user a sense of where one thought ends and the next begins. A stack of <br> elements produces no such boundary: the software reads straight through, and the structure the sighted reader sees in the spacing is invisible to the listener. Empty paragraphs used as spacers have the same problem, some screen readers announce them as blank, others skip them, and either way the gap you intended is not communicated.

The rule that survives contact with real projects: <br> only when the break is part of the data (an address, verse, a line in a form label), and vertical spacing between blocks always in CSS with margin. Structure carries meaning; style carries appearance, and keeping them apart is what makes a page both maintainable and accessible.

JunoParagraphs and line breaks Each block of text goes in its own <p>...</p>, and that is what puts space between paragraphs. The browser ignores the Enters and spaces you type, so the tags do the work. Use <br> only when a line really needs to break mid-paragraph, like an address.
JunoParagraphs and line breaks<p> for a paragraph, and the browser collapses your source whitespace so formatting the file changes nothing on the page. <br> is for breaks that belong to the content, like an address, never for pushing things apart. Two <br> to make a gap is the tell that spacing has leaked out of CSS.
JunoParagraphs and line breaks<p> is a block that gives a screen reader a real paragraph boundary to pause on; a stack of <br> gives it nothing and the structure vanishes for anyone listening. So <br> only when the break is part of the data, and all vertical spacing in CSS with margin. Empty paragraphs as spacers have the same accessibility hole, skip them too.

Emphasis: <strong> and <b>, <em> and <i>

Two elements make text bold, and two make it italic. <strong> and <b> both render bold; <em> and <i> both render italic. So four tags, two looks.

html
<p><strong>Warning:</strong> the oven is very hot.</p>
<p>You need to knead the dough <em>thoroughly</em>.</p>

For now, reach for <strong> when a bit of text is important, like a warning, and <em> when you want to stress a word the way your voice would if you were reading aloud. They are the two you will want most of the time, and the browser makes them bold and italic for you.

The four elements split into two pairs, and the split is between meaning and appearance. <strong> and <em> are semantic: they say something about the text. <b> and <i> are presentational: they only change how it looks.

Use <strong> when content carries importance, seriousness, or urgency: a warning, a critical instruction. Use <em> for stress emphasis, the word you would lean on if you read the sentence out loud, which can change its meaning. Both happen to render bold and italic respectively, but you are choosing them for what they mean.

<b> and <i> are for the cases where you want bold or italic and there is no importance or stress behind it. A <b> for a keyword you are drawing the eye to, an <i> for a ship's name or a foreign phrase. They mark text as stylistically set apart, without claiming it matters more.

html
<p><strong>Do not</strong> open the valve while the system is pressurised.</p>
<p>She whispered that it was <em>her</em> idea, not his.</p>
<p>The keyboard shortcut is <b>Ctrl</b> plus <b>S</b>.</p>
<p>We took the ferry across on the <i>Lady Marion</i>.</p>

If you only remember one thing: <strong> and <em> mean it, <b> and <i> just show it. When the text really matters, reach for the semantic pair.

All four render the same two ways a browser would by default, bold or italic, so on screen they are interchangeable. The difference is what they communicate to anything that is not looking at the pixels, and that is where the choice actually lives.

<strong> marks importance: content that is serious, urgent, or must not be missed. <em> marks stress emphasis: the word whose weight changes the meaning of the sentence (compare "call me tomorrow" with "call me tomorrow"). A screen reader can act on these. Many will shift tone or pace on emphasised text, and a <strong> can be surfaced differently from ordinary prose, so the importance you encoded is actually conveyed to someone who is not seeing the bold. Nest them for degree: <strong> inside <strong> reads as greater importance, <em> inside <em> as heavier stress.

<b> and <i> are the presentational pair, and they are the correct choice more often than "avoid them" advice suggests. Their real definitions are narrow. <b> draws attention to text for a practical reason with no added importance: a keyword in a summary, a product name in a review. <i> marks text in an alternate voice or mood: a technical term on first use, a taxonomic name like Homo sapiens, a phrase in another language, a character's inner thought. When there is a more specific element (<cite> for a work's title, <dfn> for a definition, <code> for code), use that instead; <b> and <i> are the fallback when the text is set apart but no stronger meaning applies.

The failure mode to avoid is using <b> where you mean <strong>, or <i> where you mean <em>. They look identical, so nothing on screen tells you it is wrong, but you have thrown away the importance or the emphasis that assistive technology relies on. Ask what the text means, not what it should look like: if it matters, <strong> or <em>; if it is merely set apart, <b> or <i>.

JunoEmphasis: strong and b, em and i<strong> and <b> both go bold, <em> and <i> both go italic. Starting out, reach for <strong> when something is important, like a warning, and <em> when you want to stress a word the way your voice would. Those two will cover almost everything you write.
JunoEmphasis: strong and b, em and i<strong> means important, <em> means stressed, and both carry meaning. <b> and <i> are the same bold and italic with no meaning behind them, for text you just want set apart. Same look either way, so pick the pair by what the text means, not how it should appear.
JunoEmphasis: strong and b, em and i On screen all four are just bold or italic; the difference is what a screen reader hears. <strong> and <em> encode importance and stress and can be announced differently, so grabbing <b> or <i> when you mean those quietly drops the meaning. <b> and <i> are right for text that is only set apart, a keyword or a term, when no more specific element fits.

Other inline text (quotes, <code>, <abbr>, and friends)

Beyond bold and italic, HTML has small elements for common bits of text. A short quote sits in <q>, and the browser adds the quotation marks for you. A piece of code, like the name of a command, goes in <code>, which the browser shows in a monospace font so it stands out from normal writing.

html
<p>My gran always said <q>a watched pot never boils</q>.</p>
<p>Save the file with the <code>Ctrl S</code> shortcut.</p>

There are a handful more of these, but <q> for a short quote and <code> for code are the two you will meet most. Each one wraps a little bit of text and tells the browser what it is.

These are inline elements: they wrap a run of text inside a paragraph without breaking onto their own line, unlike a block such as <p>. Each names what a fragment of text is, so reach for the specific element rather than styling a plain <span> to look the part.

The ones worth knowing:

html
<p>The report cites <cite>The Pragmatic Programmer</cite> twice.</p>
<p>Run <code>npm install</code>, then press <kbd>Enter</kbd>.</p>
<p>The room is <strong>24m<sup>2</sup></strong> of floor space.</p>
<p>The old total was <del>£40</del> <ins>£32</ins>.</p>
<p>As <abbr title="HyperText Markup Language">HTML</abbr> matures, the tags settle.</p>

<cite> names the title of a work. <code> marks code, <kbd> marks keyboard input, and <samp> marks program output. <sup> and <sub> are superscript and subscript, for things like exponents and chemical formulas. A degree sign is its own character, °, rather than a superscript. <del> and <ins> mark deleted and inserted text, useful for showing an edit or a price change. <abbr> marks an abbreviation, and its title attribute holds the full expansion.

<q> is for a short inline quote and adds quotation marks automatically. For a longer, standalone quotation you want <blockquote> instead, which is a block element.

These are inline elements, ones that flow within a line of text rather than forming their own block. They exist so that a fragment of text can carry its meaning in the markup, which is what makes that meaning available to assistive technology, search engines, and your own styling and scripts. The practical guidance is to use the most specific element that fits and to fall back to a neutral <span> only when none does.

The set you will actually use:

html
<p>See <cite>Designing Data-Intensive Applications</cite>, chapter three.</p>
<p>Type <kbd>git status</kbd> to see <samp>nothing to commit</samp>.</p>
<p>The sample used <abbr title="Cascading Style Sheets">CSS</abbr> variables throughout.</p>
<p>Revised figure: <del>1,200</del> <ins>1,450</ins> entries.</p>

<cite> marks the title of a cited work (a book, film, or paper), not a person's name, a point people get wrong constantly. <code> is a fragment of computer code and <kbd> is user keyboard input, two things that both often render monospace but mean opposite directions of the interaction. <samp> is sample output from a program. <abbr> marks an abbreviation and takes a title attribute holding the full expansion; a screen reader can announce or offer that expansion, and it appears as a tooltip on hover, so the reader is never left guessing what the letters stand for. <del> and <ins> represent an edit, text removed and text added, and are announced as such, which matters where the change is the point, like a price correction or a redline.

For quotations, <q> is inline and inserts locale-aware quotation marks through CSS (which is why you do not type the marks yourself), while <blockquote> is the block-level element for an extended quotation, and both take an optional cite attribute holding the URL of the source. The through-line across all of these: the element is the meaning, and appearance is a separate layer you set in CSS. Choosing the tag for what the text is, rather than for a monospace or italic look, is what keeps the page legible to the tools that cannot see it.

JunoOther inline text (quotes, code, abbr, and friends)<q> wraps a short quote and adds the quotation marks for you, and <code> shows code in a monospace font so it stands out. There are a few more of these little tags, but those two come up the most. Each one just wraps a bit of text and says what it is.
JunoOther inline text (quotes, code, abbr, and friends) These inline tags each name what a fragment is: <code> for code, <kbd> for keys pressed, <cite> for a work's title, <abbr> with a title for the full form. Reach for the specific one instead of styling a plain <span>. And <q> for a short quote, <blockquote> for a standalone one.
JunoOther inline text (quotes, code, abbr, and friends) Use the most specific inline element and fall back to <span> only when nothing fits. Watch the ones people misuse: <cite> is a work's title, not a person, and <code> versus <kbd> look alike but mean opposite ends of the interaction. <abbr>'s title is read out by assistive tech, and <q> supplies its own quotation marks, so don't type them.