HTML Head Element

The <head> element is the part of an HTML document that holds information about the page rather than content the visitor reads. It never displays directly in the page body, but almost everything that makes a page work well — its title, its character encoding, its stylesheets, its search-engine description — lives inside it. Get the <head> wrong and a page can still look fine at a glance while quietly failing on mobile devices, in search results, or when shared on social media.

Overview: What the head Element Is For

Every valid HTML document has exactly one <html> root element, and inside it, exactly one <head> and one <body>. The <body> contains everything the user sees rendered on screen: paragraphs, images, links, forms. The <head> contains metadata: data describing the document itself, instructions for the browser, and links to external resources the page depends on.

Metadata elements are non-visual by nature. If you put a <p> or a piece of plain text inside <head>, most browsers will not render it where you wrote it — the HTML parser actually recognizes that visible content does not belong in the head, and it implicitly closes the <head> element and starts the <body> at that point. This “error recovery” behavior is part of the HTML parsing algorithm, not a lucky accident, but relying on it produces confusing, hard-to-maintain markup, so you should never place visible content inside <head> on purpose.

The elements that are actually allowed inside <head> are a specific, limited set:

Element Purpose
title The document’s title, shown in the browser tab and used as the default bookmark/search-result title. Required in every HTML document.
meta Key/value metadata: character encoding, viewport behavior, page description, author, robots directives, and more.
link Links to external resources: stylesheets, icons, preconnect hints, alternate versions of the page.
style An embedded block of CSS that applies to the document (a CSS course covers its syntax in depth).
script Embedded or linked JavaScript (covered in a JavaScript course).
base Sets a default URL and/or target for every relative link and form on the page. At most one per document.
noscript Fallback content for when scripting is disabled, when used as a direct child of head it must only contain link, style, and meta elements.

The <head> is invisible in the rendered page, but it is not optional busywork. The character-encoding declaration affects whether every letter on the page displays correctly. The viewport meta tag determines whether a mobile visitor sees a usable page or a tiny, zoomed-out desktop layout. The title and description meta tags are what a user actually sees first, in a browser tab or in a search engine’s results list, before they ever load the page.

Syntax

<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Page Title</title>
    <meta name="description" content="...">
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    ...
  </body>
</html>
  • Placement: <head> must be the first child of <html>, immediately followed by <body>.
  • No attributes of its own: <head> only accepts the global HTML attributes (like lang on the surrounding <html> element, or id); it has no attributes specific to itself.
  • title is mandatory: every document’s head should contain exactly one <title> element with non-empty text.
  • Order matters somewhat: put <meta charset> first, since the browser must know the encoding before it can correctly parse later characters (including in the title).

Examples

Example 1: A Minimal but Correct head

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My First Page</title>
</head>
<body>
  <h1>Hello, World</h1>
</body>
</html>

Result: The browser tab shows “My First Page”. Nothing from the head itself appears in the visible page area; only the <h1> heading “Hello, World” renders in the body. The page renders at a correct, non-zoomed width on a phone because of the viewport meta tag.

This is the smallest head that is still considered good practice: a character encoding, a responsive viewport setting, and a meaningful title. Skipping any of these three is a common source of subtle bugs.

Example 2: A head With SEO and Icon Metadata

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Homemade Bread Recipes | The Baking Blog</title>
  <meta name="description" content="Simple, tested recipes for homemade bread, from beginner loaves to sourdough.">
  <meta name="author" content="Jordan Lee">
  <link rel="icon" href="/favicon.ico">
  <link rel="stylesheet" href="/css/site.css">
</head>
<body>
  <h1>The Baking Blog</h1>
  <p>Recipes and tips for home bakers.</p>
</body>
</html>

Result: The browser tab shows both a small favicon icon and the title “Homemade Bread Recipes | The Baking Blog”. The page loads the external stylesheet at /css/site.css to control its appearance. None of the meta tags produce visible text on the page — the description and author are only read by search engines, browsers, and other tools, not shown to the visitor directly.

This example shows the head doing real work for discoverability: the description meta tag is frequently shown verbatim as the snippet under a search result link, and the favicon gives the tab a recognizable icon among many open tabs.

Example 3: Using base and Multiple link Elements

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <base href="https://example.com/docs/">
  <title>Getting Started</title>
  <link rel="stylesheet" href="theme.css">
  <link rel="preconnect" href="https://fonts.example.com">
  <link rel="canonical" href="https://example.com/docs/getting-started">
</head>
<body>
  <a href="install.html">Installation guide</a>
</body>
</html>

Result: Even though the page might be served from a different URL, every relative link and resource on the page resolves against https://example.com/docs/. The link labeled “Installation guide” actually points to https://example.com/docs/install.html, and theme.css is fetched from https://example.com/docs/theme.css, because of the <base> element.

The preconnect link is a performance hint telling the browser to start a network connection to that domain early, before it is actually needed. The canonical link tells search engines which URL is the “official” one for this content, useful when the same page is reachable through more than one address.

How the Browser Parses the head

When a browser receives an HTML document, it builds the DOM tree top to bottom as it reads bytes. The moment it sees <head> (or, if you omit the tag, the moment it sees a metadata element like <meta> or <title> right after <html>), it opens a head node and starts inserting metadata children into it.

Because the head is processed before the body, anything declared there is known to the browser before rendering of visible content begins. This is why the character encoding must come first: text after the <meta charset> tag, including the title itself, is interpreted using that encoding, so if it comes too late, earlier bytes may already have been misread. Similarly, an external stylesheet linked in the head is requested as soon as the parser reaches that <link> tag — well before the body’s elements exist — which is precisely why CSS placed in the head is able to style the page without a visible “flash” of unstyled content.

If the parser encounters something that cannot legally live in the head — ordinary text, or an element like <p> or <div> — the HTML parsing algorithm treats that as the signal that the head is finished. It automatically closes <head> and opens <body>, then inserts that content into the body instead. This is a deliberate error-recovery rule defined in the HTML parsing spec, and every major browser implements it identically, but it means a missing closing tag or a misplaced element doesn’t necessarily throw a visible error — it just silently reshapes your document tree in a way you didn’t intend.

Common Mistakes

Mistake 1: Putting visible content inside head.

<head>
  <title>My Page</title>
  <h1>Welcome!</h1>
</head>

This is invalid: <h1> is flow content, not metadata, and is not allowed as a child of <head>. Browsers will move it into <body> for you, but this makes the source misleading to any human (or tool) reading it, since the markup no longer matches what actually renders. Keep headings in the body:

<head>
  <title>My Page</title>
</head>
<body>
  <h1>Welcome!</h1>
</body>

Mistake 2: Multiple title elements, or none at all.

<head>
  <meta charset="utf-8">
</head>

This head has no <title> at all. The tab will show a fallback like the file name or URL, and search engines and screen readers, which rely on the title to identify the page, lose useful information. Every document needs exactly one non-empty <title>:

<head>
  <meta charset="utf-8">
  <title>Contact Us</title>
</head>

Mistake 3: Declaring charset after other content or omitting it. Placing <meta charset> late, or leaving it out entirely, risks the browser guessing the wrong encoding and displaying garbled characters (especially accented letters or non-Latin scripts). Always make it the very first element inside <head>.

Best Practices

  • Always include <meta charset="utf-8"> as the first line inside <head>.
  • Always include a responsive viewport tag: <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Write a unique, descriptive <title> for every page — it is one of the strongest signals for SEO and the first thing users see in a browser tab or search result.
  • Add a <meta name="description"> summarizing the page in one or two sentences; it is often shown directly as the search-result snippet.
  • Load stylesheets via <link rel="stylesheet"> in the head so the page is styled before it becomes visible, rather than embedding large style blocks.
  • Use <base> sparingly, and only once per document — it silently changes every relative URL on the page, which can surprise later maintainers.
  • Never place visible text or body-only elements directly inside <head>.
  • Keep the head lean: only include metadata and resources the page actually needs, since everything in the head can delay when the body starts rendering.

Practice Exercises

  1. Write a complete HTML document whose head includes a UTF-8 charset declaration, a viewport meta tag, a title of “About Our Team”, and a meta description of your choosing. Add a single heading in the body.
  2. Take a document where <meta name="viewport"> is missing, and add it. Explain in your own words what visibly changes when the page is opened on a narrow (phone-width) screen versus without it.
  3. Write a head that links to two external stylesheets and one favicon, then add a <base href="..."> element and explain how it changes where a relative link like href="page2.html" in the body would actually point.

Summary

  • The <head> element holds a document’s metadata: the title, character encoding, viewport settings, linked stylesheets/icons, and search-engine description, among other things.
  • It contains no visible content; only specific metadata elements (title, meta, link, style, script, base, noscript) are valid children.
  • The browser parses and processes the head before rendering the body, which is why encoding, viewport, and stylesheet declarations belong there.
  • Placing visible content inside <head> triggers automatic error recovery that moves it into <body>, which is confusing and should be avoided.
  • A well-formed head always has exactly one <title>, a charset declaration first, and a viewport meta tag for mobile-friendly rendering.