HTML Guides
Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.
A character encoding declaration tells the browser how to interpret the raw bytes of your document into readable characters. For HTML documents, the standard way to declare this is with <meta charset="utf-8">. The HTML specification requires that this element be serialized completely within the first 1024 bytes of the document. This means that everything from the start of the file—including the doctype, the <html> tag, the <head> tag, and the <meta charset> element itself—must fit within that 1024-byte window.
If the <meta charset> element appears after the first 1024 bytes, the browser must use other heuristics or fallback encodings to guess how to decode the document. This can cause several problems:
- Garbled or broken text: Characters outside the ASCII range (such as accented letters, CJK characters, or emoji) may render incorrectly.
- Security vulnerabilities: Certain encoding-sniffing behaviors have historically been exploited for cross-site scripting (XSS) attacks, which is one reason the spec enforces this strict limit.
- Inconsistent rendering: Different browsers may fall back to different default encodings, meaning your page could look different depending on the user’s browser or system locale.
This issue typically occurs when a large number of <meta> tags, inline <style> blocks, lengthy comments, or <script> elements are placed in the <head> before the <meta charset> declaration. Even excessive whitespace or server-injected content can push it past the 1024-byte boundary.
To fix this, ensure that <meta charset="utf-8"> is the first child element of <head>, appearing before any <title>, <link>, <script>, <style>, or other <meta> tags. Remove or relocate any unnecessary content that precedes it.
Examples
❌ Incorrect: <meta charset> pushed past 1024 bytes
In this example, a large inline style block and several meta tags appear before the charset declaration, easily exceeding the 1024-byte limit:
<!DOCTYPE html>
<html lang="en">
<head>
<meta name="description" content="A very long description...">
<meta name="keywords" content="many, keywords, here, ...">
<meta name="author" content="Some Author">
<link rel="stylesheet" href="styles.css">
<style>
/* Hundreds of bytes of inline CSS rules...
...pushing the total well past 1024 bytes
before the charset declaration appears */
body { font-family: sans-serif; margin: 0; padding: 0; }
.container { max-width: 1200px; margin: 0 auto; }
/* ...many more rules... */
</style>
<meta charset="utf-8">
<title>My Page</title>
</head>
<body>
<p>Hello world</p>
</body>
</html>✅ Correct: <meta charset> as the first element in <head>
Move the charset declaration to the very first position inside <head>:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My Page</title>
<meta name="description" content="A very long description...">
<meta name="keywords" content="many, keywords, here, ...">
<meta name="author" content="Some Author">
<link rel="stylesheet" href="styles.css">
<style>
body { font-family: sans-serif; margin: 0; padding: 0; }
.container { max-width: 1200px; margin: 0 auto; }
</style>
</head>
<body>
<p>Hello world</p>
</body>
</html>✅ Minimal correct example
For simpler documents, the pattern is straightforward—just keep <meta charset> first:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My Page</title>
</head>
<body>
<p>Hello world</p>
</body>
</html>As a general rule of thumb, always make <meta charset="utf-8"> the very first thing after the opening <head> tag. This guarantees it falls well within the 1024-byte limit regardless of what follows, and it ensures the browser knows the correct encoding before it encounters any other content.
Both <meta charset="UTF-8"> and <meta http-equiv="content-type" content="text/html; charset=UTF-8"> instruct the browser which character encoding to use when interpreting the document’s bytes into text. Having both declarations in the same document creates a redundant and potentially conflicting situation. The HTML specification explicitly forbids including both, because if they ever specified different encodings, the browser would have to decide which one to trust, leading to unpredictable behavior.
Character encoding is critical for correctly displaying text. If the encoding is wrong or ambiguous, characters like accented letters, emoji, or symbols from non-Latin scripts can appear as garbled text (often called “mojibake”). By requiring a single, unambiguous declaration, the spec ensures browsers can reliably determine the encoding.
The <meta charset="UTF-8"> syntax was introduced with HTML5 as a shorter, cleaner alternative to the older <meta http-equiv="content-type"> approach. Both are valid on their own, but modern best practice strongly favors <meta charset="UTF-8"> for its simplicity. Whichever you choose, it should appear as early as possible within the <head> element — ideally as the first child — and must appear within the first 1024 bytes of the document so the browser can detect the encoding before parsing the rest of the content.
To fix this issue, search your document’s <head> for both forms of the declaration and remove one of them. In most cases, you should keep <meta charset="UTF-8"> and remove the <meta http-equiv="content-type"> element.
Examples
Incorrect: both declarations present
This triggers the validation error because both methods of declaring the character encoding are used simultaneously.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>Correct: using <meta charset> (recommended)
This is the modern, preferred approach for HTML5 documents.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>Correct: using <meta http-equiv="content-type">
This older syntax is also valid on its own. You might encounter it in legacy codebases or when serving documents as application/xhtml+xml.
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>Common scenario: declarations split across includes
In templating systems or CMS platforms, the two declarations sometimes end up in different partial files — for example, one in a base layout and another injected by a plugin or theme. If you encounter this error unexpectedly, check all files that contribute to your <head> section, not just the main template.
<!-- base-layout.html -->
<head>
<meta charset="UTF-8">
<!-- ...other tags... -->
</head>
<!-- plugin-head-snippet.html (remove this duplicate) -->
<meta http-equiv="content-type" content="text/html; charset=UTF-8">Audit your includes and partials to ensure only one character encoding declaration ends up in the final rendered <head>.
The <meta charset> element tells the browser which character encoding to use when interpreting the bytes of the HTML document. The HTML specification explicitly states that there must be no more than one <meta> element with a charset attribute per document. This declaration should appear within the first 1024 bytes of the document, so placing it as the first child of <head> (right after the opening <head> tag) is the recommended practice.
Duplicate charset declarations typically happen when code is assembled from multiple templates, partials, or snippets — each contributing its own <meta charset>. It can also occur when a developer manually adds a charset declaration without realizing one is already present, or when migrating from an older <meta http-equiv="Content-Type"> approach and adding a new <meta charset> without removing the old equivalent.
Why this matters
- Standards compliance: The WHATWG HTML living standard mandates at most one <meta charset> per document. Violating this produces a validation error.
- Unpredictable behavior: When a browser encounters conflicting or duplicate charset declarations, the behavior is undefined. While most modern browsers will use the first one encountered, relying on this is fragile and could lead to garbled text or encoding issues in edge cases.
- Maintainability: Multiple charset declarations signal disorganized or duplicated template logic, making the codebase harder to maintain.
How to fix it
- Search your HTML document (including any templates, layouts, or partials that compose the final output) for all instances of <meta charset> or <meta charset="...">.
- Keep exactly one <meta charset="utf-8"> declaration, placed as the first element inside <head>.
- Remove all other <meta charset> elements.
- If you also have a legacy <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, remove it — the shorter <meta charset="utf-8"> form is the modern replacement, and having both counts as duplicate charset declarations.
Examples
❌ Incorrect: multiple charset declarations
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta charset="utf-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>The second <meta charset="utf-8"> triggers the validation error, even though both specify the same encoding.
❌ Incorrect: mixing old and new charset syntax
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>Both elements declare a character encoding, so the validator treats this as a duplicate.
✅ Correct: single charset declaration
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>A single <meta charset="utf-8"> appears first in <head>, before any other elements or content. This is the correct and recommended approach. UTF-8 is the strongly recommended encoding for all new HTML documents.
The <meta name="description"> element provides a brief summary of a page’s content. According to the WHATWG HTML living standard, there must be no more than one <meta> element per document where the name attribute has the value "description". This is a conformance requirement — not just a best practice — meaning that including duplicates produces invalid HTML.
Why this matters
Standards compliance: The HTML specification explicitly states that certain metadata names, including "description", must be unique within a document. Violating this makes your HTML non-conforming.
Search engine behavior: Search engines like Google use the meta description to generate snippet text in search results. When multiple description meta tags are present, search engines must decide which one to use — or may ignore them entirely and pull text from the page body instead. This can result in a less relevant or less compelling snippet, potentially reducing click-through rates.
Maintainability: Duplicate meta descriptions often arise from template conflicts — for example, a CMS injecting one description while a theme or plugin adds another. Having duplicates makes it unclear which description is actually intended, creating confusion for developers maintaining the code.
Common causes
- A CMS or static site generator automatically inserts a <meta name="description"> tag, while the template or theme also hardcodes one.
- Multiple HTML partials or includes each contribute their own description meta tag to the <head>.
- Copy-paste errors when building or editing the <head> section.
How to fix it
- Search your HTML source for all instances of <meta name="description".
- Decide which description best represents the page’s content.
- Remove all duplicate instances, keeping only one.
- If your content comes from templates or includes, trace where each tag is generated and ensure only one source outputs the description.
Examples
❌ Invalid: duplicate description meta tags
<!DOCTYPE html>
<html lang="en">
<head>
<title>About Us</title>
<meta name="description" content="Learn about our company and mission.">
<meta name="description" content="We are a team of passionate developers.">
</head>
<body>
<h1>About Us</h1>
<p>Welcome to our about page.</p>
</body>
</html>The validator will report an error because two <meta> elements share name="description".
✅ Valid: single description meta tag
<!DOCTYPE html>
<html lang="en">
<head>
<title>About Us</title>
<meta name="description" content="Learn about our company, mission, and the team of passionate developers behind it.">
</head>
<body>
<h1>About Us</h1>
<p>Welcome to our about page.</p>
</body>
</html>Here, the two descriptions have been merged into a single, more comprehensive meta description. Alternatively, you could simply keep whichever original description was more accurate and discard the other.
❌ Invalid: duplicates from mixed sources (common template issue)
<head>
<title>Blog Post</title>
<!-- Injected by CMS -->
<meta name="description" content="Auto-generated summary of the blog post.">
<!-- Hardcoded in theme template -->
<meta name="description" content="A blog about web development tips and tricks.">
<meta name="author" content="Jane Smith">
</head>✅ Valid: single source of truth
<head>
<title>Blog Post</title>
<!-- Injected by CMS (theme duplicate removed) -->
<meta name="description" content="Auto-generated summary of the blog post.">
<meta name="author" content="Jane Smith">
</head>When fixing template-driven duplicates, decide which system should own the description — typically the CMS, since it can generate page-specific descriptions — and remove the hardcoded one from the theme.
Make sure your final <meta name="description"> content is meaningful, concise (typically 150–160 characters), and accurately reflects what visitors will find on the page.
The <main> element represents the dominant, unique content of a document — the primary content that is directly related to or expands upon the central topic of the page. Having more than one visible <main> element creates ambiguity: browsers, screen readers, and other assistive technologies use <main> to identify the primary content area, and multiple visible instances make it unclear which content block is truly the main one.
This is particularly important for accessibility. Screen reader users often rely on landmark navigation to jump directly to the main content of a page. When multiple visible <main> elements exist, this shortcut becomes unreliable or confusing, as the user has no way to know which <main> holds the content they’re looking for.
There are legitimate scenarios where multiple <main> elements make sense — for example, in single-page applications (SPAs) where different views are swapped in and out dynamically using JavaScript. The HTML specification accommodates this by allowing multiple <main> elements as long as only one is visible at a time. The others must be hidden using the hidden attribute.
How to fix it
- If you only need one main content area, remove the extra <main> elements and keep just one.
- If you need multiple views (e.g., for tabbed content or SPA-style navigation), add the hidden attribute to all <main> elements except the one currently active. Use JavaScript to toggle visibility by adding or removing the hidden attribute as needed.
Examples
❌ Invalid: Two visible <main> elements
<header>
<h1>My Website</h1>
</header>
<main>
<h2>Welcome</h2>
<p>This is the home page content.</p>
</main>
<main>
<h2>About</h2>
<p>This is the about page content.</p>
</main>Both <main> elements are visible, which violates the specification and confuses assistive technologies.
✅ Fixed: Single <main> element
If you don’t need multiple views, simply use one <main>:
<header>
<h1>My Website</h1>
</header>
<main>
<h2>Welcome</h2>
<p>This is the home page content.</p>
</main>✅ Fixed: Multiple <main> elements with only one visible
If you need multiple views for JavaScript-driven navigation, hide all but the active one using the hidden attribute:
<header>
<nav>
<button onclick="switchView('home')">Home</button>
<button onclick="switchView('about')">About</button>
</nav>
</header>
<main id="home">
<h2>Welcome</h2>
<p>This is the home page content.</p>
</main>
<main id="about" hidden>
<h2>About</h2>
<p>This is the about page content.</p>
</main>In this pattern, JavaScript would toggle the hidden attribute when the user navigates between views, ensuring only one <main> is ever visible at a time.
❌ Invalid: Using CSS instead of hidden
Note that hiding a <main> element with CSS (e.g., display: none or visibility: hidden) does not satisfy the HTML specification. The validator checks for the hidden attribute, not CSS styles:
<!-- This still triggers the validation error -->
<main>
<h2>Welcome</h2>
</main>
<main style="display: none;">
<h2>About</h2>
</main>Always use the hidden attribute to indicate that a <main> element is not currently relevant to the page.
The HTML <figure> element represents self-contained content — such as an image, diagram, code snippet, or quotation — optionally accompanied by a caption provided by a <figcaption> element. When a <figcaption> is present, the browser and assistive technologies already understand the relationship between the figure and its caption. This built-in semantic relationship is part of the ARIA in HTML specification, which governs how native HTML elements map to accessibility roles.
The role attribute is typically used to assign or override the ARIA role of an element for assistive technologies like screen readers. However, the ARIA in HTML specification explicitly restricts certain role assignments when an element’s native semantics are already well-defined by its content. A <figure> with a <figcaption> is one such case — the presence of the caption establishes a clear semantic structure that the role attribute would interfere with.
This restriction exists for several important reasons:
- Accessibility conflicts: Adding role="figure" is redundant since the element already has that implicit role. Adding a different role (like role="img" or role="group") could confuse assistive technologies by contradicting the semantic meaning established by the <figcaption>. Screen readers may ignore the caption or announce the element incorrectly.
- Standards compliance: The ARIA in HTML specification states that when a <figure> has a <figcaption> descendant, no role attribute is allowed. The W3C validator enforces this rule.
- Maintainability: Relying on native HTML semantics rather than ARIA overrides keeps your markup simpler and less error-prone. The first rule of ARIA is: “If you can use a native HTML element with the semantics and behavior you require already built in, do so.”
To fix this issue, remove the role attribute from the <figure> element. The <figcaption> provides all the semantic context needed.
Examples
Incorrect: role attribute on <figure> with <figcaption>
Adding role="figure" is redundant and triggers the validation error:
<figure role="figure">
<img src="chart.png" alt="Sales data for Q3 2024">
<figcaption>Figure 1: Quarterly sales by region.</figcaption>
</figure>Using a different role like role="img" also triggers the error and can cause accessibility problems:
<figure role="img">
<img src="chart.png" alt="Sales data for Q3 2024">
<figcaption>Figure 1: Quarterly sales by region.</figcaption>
</figure>Correct: <figure> with <figcaption> and no role
Simply remove the role attribute. The <figure> and <figcaption> elements handle semantics on their own:
<figure>
<img src="chart.png" alt="Sales data for Q3 2024">
<figcaption>Figure 1: Quarterly sales by region.</figcaption>
</figure>Correct: <figure> without <figcaption> can use a role
If you have a <figure> without a <figcaption>, the restriction does not apply. In this case, you may use a role attribute if needed:
<figure role="img" aria-label="Sales data for Q3 2024">
<img src="chart.png" alt="">
</figure>Correct: <figure> with <figcaption> containing other media
The fix applies regardless of the type of content inside the <figure>:
<figure>
<pre><code>const greeting = "Hello, world!";</code></pre>
<figcaption>A simple variable assignment in JavaScript.</figcaption>
</figure><figure>
<blockquote>
<p>The best way to predict the future is to invent it.</p>
</blockquote>
<figcaption>Alan Kay</figcaption>
</figure>In every case, the <figcaption> provides the accessible name and descriptive context for the <figure>, making any role attribute unnecessary and non-conformant.
The <link> element defines a relationship between the current document and an external resource — most commonly stylesheets, icons, preloaded assets, or canonical URLs. According to the HTML specification, the element must include at least one of the href or imagesrcset attributes so the browser knows what resource is being linked. A <link> element without either attribute is essentially an empty declaration: it tells the browser about a relationship type (via rel) but provides no actual resource to fetch or reference.
This validation error commonly occurs in a few scenarios:
- Templating or CMS issues: A dynamic template generates a <link> tag but the URL variable is empty or undefined, resulting in a bare element with no href.
- Incomplete code: A developer adds a <link> with a rel attribute intending to fill in the href later but forgets to do so.
- Copy-paste mistakes: Attributes are accidentally removed during editing or refactoring.
Fixing this is important for several reasons. Browsers may ignore the element entirely or behave unpredictably when encountering a <link> with no resource URL. Unnecessary elements without purpose add bloat to the document and can confuse other developers reading the code. Additionally, tools that parse HTML — such as search engine crawlers and assistive technologies — rely on well-formed markup to correctly understand document relationships.
To resolve the issue, add an href attribute pointing to the target resource, use an imagesrcset attribute when providing responsive image sources, or include both when appropriate.
Examples
Invalid: missing both href and imagesrcset
This <link> declares a stylesheet relationship but doesn’t specify where the stylesheet is located:
<link rel="stylesheet">This preload link has an as attribute but no resource to fetch:
<link rel="preload" as="image" type="image/png">Fixed: using href
The most common fix is adding an href attribute with a valid URL:
<link rel="stylesheet" href="styles.css"><link rel="icon" href="favicon.ico"><link rel="canonical" href="https://example.com/page">Fixed: using imagesrcset
For responsive image preloading, the imagesrcset attribute specifies multiple image sources at different resolutions. This is valid without href:
<link rel="preload" as="image" type="image/png" imagesrcset="icon-1x.png 1x, icon-2x.png 2x">Fixed: using both href and imagesrcset
You can combine both attributes. The href serves as a fallback resource while imagesrcset provides responsive alternatives:
<link rel="preload" as="image" href="icon-1x.png" imagesrcset="icon-1x.png 1x, icon-2x.png 2x">Handling dynamic templates
If your <link> elements are generated dynamically, make sure the element is only rendered when a valid URL is available. For example, in a template, wrap the output in a conditional check rather than outputting an empty <link>:
<!-- Bad: outputs a link even when the URL is empty -->
<link rel="stylesheet" href="">
<!-- Good: only include the element when there's a real URL -->
<link rel="stylesheet" href="styles.css">Note that href="" resolves to the current page URL and is technically valid syntax (it won’t trigger this specific error), but it’s almost certainly not what you intend. Always ensure the href value points to the correct resource.
The HTML specification restricts where <link> elements can appear based on their purpose. Links that load resources needed for rendering (like stylesheets and preloaded assets) or carry microdata (itemprop) are allowed in <body> because they have a direct relationship to the content around them. Other types of <link> elements—canonical URLs, icons, alternate versions—are document-level metadata and belong exclusively in <head>.
This matters for several reasons. Browsers may ignore or inconsistently handle <link> elements placed in unexpected locations, leading to issues like missing canonical signals for search engines or broken favicon references. Standards compliance also ensures your HTML is forward-compatible and behaves predictably across all browsers.
Common causes
Direct placement in <body>
The most straightforward cause is placing a metadata <link> directly inside <body>, often due to a CMS, template system, or plugin injecting it in the wrong location.
Implicit <body> creation by the parser
A subtler cause occurs when an element that’s only valid in <body> appears inside <head>. When the HTML parser encounters such an element (like <img>, <div>, or <p>), it implicitly closes the <head> and opens the <body>. Any <link> elements that follow are then treated as descendants of <body>, even though they appear to be inside <head> in your source code.
For example, an <img> tag in the <head> causes the parser to switch to body context, so the subsequent <link rel="canonical"> is interpreted as being inside <body> and triggers this error.
How to fix it
-
Move disallowed <link> elements to <head>: If a <link> with rel="canonical", rel="icon", rel="alternate", or similar values is in <body>, move it into <head>.
-
Check for body-only elements in <head>: Look for elements like <img>, <div>, <p>, <script> (without src), or text content that may have been accidentally placed in <head>. These cause the parser to implicitly close <head>, making everything after them part of <body>.
-
Use allowed rel values if a body placement is intentional: If you genuinely need a <link> in <body>, ensure it uses one of the permitted rel values (stylesheet, preload, prefetch, preconnect, dns-prefetch, modulepreload, pingback, prerender) or has an itemprop attribute.
Examples
❌ <link rel="canonical"> placed in <body>
<body>
<link rel="canonical" href="https://example.com/page">
<h1>Welcome</h1>
</body>✅ Move it to <head>
<head>
<title>My Page</title>
<link rel="canonical" href="https://example.com/page">
</head>
<body>
<h1>Welcome</h1>
</body>❌ An <img> in <head> forces implicit body context
Even though the <link> appears to be in <head>, the <img> causes the parser to switch to body context:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Test</title>
<img src="photo.jpg" alt="A smiling cat">
<link rel="canonical" href="https://example.com/">
</head>
<body>
<p>Some content</p>
</body>
</html>✅ Move the <img> to <body> where it belongs
<!DOCTYPE html>
<html lang="en">
<head>
<title>Test</title>
<link rel="canonical" href="https://example.com/">
</head>
<body>
<img src="photo.jpg" alt="A smiling cat">
<p>Some content</p>
</body>
</html>✅ Allowed <link> elements inside <body>
These are valid because they use permitted rel values:
<body>
<article>
<link rel="stylesheet" href="article-theme.css">
<h2>Article Title</h2>
<p>Content here.</p>
</article>
<link rel="prefetch" href="/next-page.html">
<link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin>
</body>✅ Using itemprop for microdata
A <link> with an itemprop attribute is also valid inside <body>:
<body>
<div itemscope itemtype="https://schema.org/Product">
<span itemprop="name">Widget</span>
<link itemprop="availability" href="https://schema.org/InStock">
</div>
</body>The preload value of the <link> element’s rel attribute lets you declare fetch requests in the HTML <head>, telling the browser to start loading critical resources early in the page lifecycle—before the main rendering machinery kicks in. This can significantly improve performance by ensuring key assets are available sooner and are less likely to block rendering.
However, a preload hint is incomplete without the as attribute. The as attribute tells the browser what kind of resource is being fetched. This matters for several important reasons:
- Request prioritization: Browsers assign different priorities to different resource types. A stylesheet is typically higher priority than an image. Without as, the browser cannot apply the correct priority, and the preloaded resource may be fetched with a low default priority, undermining the purpose of preloading.
- Content Security Policy (CSP): CSP rules are applied based on resource type (e.g., script-src, style-src). Without knowing the type, the browser cannot enforce the appropriate policy.
- Correct Accept header: The as value determines which Accept header the browser sends with the request. For example, an image request sends a different Accept header than a script request. An incorrect or missing header could lead to unexpected responses from the server.
- Cache matching: When the resource is later requested by a <script>, <link rel="stylesheet">, or other element, the browser needs to match it against the preloaded resource in its cache. Without as, the browser may not recognize the preloaded resource and could fetch it again, resulting in a duplicate request—the opposite of what you intended.
The HTML specification explicitly requires the as attribute when rel="preload" is used, making this a conformance error.
Common as Values
The as attribute accepts a specific set of values. Here are the most commonly used ones:
| Value | Resource Type |
|---|---|
| script | JavaScript files |
| style | CSS stylesheets |
| font | Web fonts |
| image | Images |
| fetch | Resources fetched via fetch() or XMLHttpRequest |
| document | HTML documents (for <iframe>) |
| audio | Audio files |
| video | Video files |
| track | WebVTT subtitle tracks |
| worker | Web workers or shared workers |
Examples
Incorrect: Missing as attribute
This will trigger the validation error because the browser doesn’t know what type of resource is being preloaded:
<link rel="preload" href="/fonts/roboto.woff2"><link rel="preload" href="/js/app.js">Correct: as attribute included
Adding the appropriate as value tells the browser exactly what kind of resource to expect:
<link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin><link rel="preload" href="/js/app.js" as="script"><link rel="preload" href="/css/main.css" as="style"><link rel="preload" href="/images/hero.webp" as="image">Note on fonts and crossorigin
When preloading fonts, you must also include the crossorigin attribute, even if the font is hosted on the same origin. This is because font fetches are CORS requests by default. Without crossorigin, the preloaded font won’t match the later font request and will be fetched twice:
<!-- Correct: includes both as and crossorigin for fonts -->
<link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin>Full document example
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Preload Example</title>
<link rel="preload" href="/css/main.css" as="style">
<link rel="preload" href="/js/app.js" as="script">
<link rel="preload" href="/fonts/roboto.woff2" as="font" type="font/woff2" crossorigin>
<link rel="stylesheet" href="/css/main.css">
</head>
<body>
<h1>Hello, world!</h1>
<script src="/js/app.js"></script>
</body>
</html>Choosing the correct as value is straightforward—just match it to how the resource will ultimately be used on the page. If you’re preloading a stylesheet, use as="style"; if it’s a script, use as="script", and so on.
The as attribute specifies the type of content a <link> element is fetching — such as "style", "script", "font", or "image". The browser uses this information to set the correct request headers, apply the right Content Security Policy, and assign the appropriate priority to the request. However, the HTML specification restricts the as attribute to <link> elements whose rel attribute is either "preload" or "modulepreload". Using as with any other rel value (like "stylesheet", "icon", or a missing rel altogether) is invalid HTML.
This validation error commonly occurs in two scenarios:
- You intended to preload a resource but forgot to set rel="preload" — for example, writing <link href="styles.css" as="style"> without specifying rel.
- You added as to a regular <link> by mistake — for example, writing <link rel="stylesheet" href="styles.css" as="style">, where as is unnecessary because rel="stylesheet" already tells the browser what type of resource it is.
Getting this right matters for several reasons. Browsers rely on valid rel values to determine how to handle linked resources. An incorrect combination may cause the browser to ignore the as attribute entirely, leading to double-fetching of resources or incorrect prioritization. Additionally, invalid HTML can cause unpredictable behavior across different browsers.
How to fix it
- If you want to preload a resource (font, stylesheet, image, script, etc.), set rel="preload" and keep the as attribute.
- If you want to preload a JavaScript module, set rel="modulepreload". The as attribute defaults to "script" for module preloads and is optional in that case.
- If you’re using a different rel value like "stylesheet" or "icon", remove the as attribute — it’s not needed and not allowed.
Examples
Incorrect: as attribute without rel="preload"
This <link> has as="style" but no rel attribute:
<link href="styles.css" as="style">Incorrect: as attribute with rel="stylesheet"
The as attribute is not valid on a stylesheet link:
<link rel="stylesheet" href="styles.css" as="style">Correct: preloading a stylesheet
Use rel="preload" with the as attribute to hint the resource type:
<link rel="preload" href="styles.css" as="style">Note that preloading a stylesheet doesn’t apply it — you still need a separate <link rel="stylesheet"> to actually use the CSS.
Correct: preloading a font
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>The crossorigin attribute is required when preloading fonts, even if they’re served from the same origin.
Correct: preloading a JavaScript module
<link rel="modulepreload" href="app.js">With rel="modulepreload", the as attribute defaults to "script", so you can omit it. You may still include it explicitly if you prefer:
<link rel="modulepreload" href="app.js" as="script">Correct: regular stylesheet (no as needed)
If you simply want to load a stylesheet, no as attribute is required:
<link rel="stylesheet" href="styles.css">Full document example
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Preload Example</title>
<!-- Preload critical resources -->
<link rel="preload" href="styles.css" as="style">
<link rel="preload" href="hero.jpg" as="image">
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
<!-- Apply the stylesheet -->
<link rel="stylesheet" href="styles.css">
</head>
<body>
<h1>Hello, World!</h1>
<img src="hero.jpg" alt="Hero banner">
</body>
</html>The X-UA-Compatible meta tag was originally introduced to control which rendering engine Internet Explorer would use to display a page. Developers could force IE to emulate older versions (e.g., IE=7, IE=9) or use the latest available engine with IE=edge. The value IE=edge,chrome=1 was also commonly used to activate the Google Chrome Frame plugin, which allowed Internet Explorer to use Chrome’s rendering engine instead.
The HTML specification now only permits the value IE=edge for this meta tag. Other values are considered invalid for several reasons:
- Google Chrome Frame is discontinued. The chrome=1 directive targeted a plugin that was retired in February 2014 and is no longer supported by any browser.
- Legacy IE rendering modes are obsolete. Internet Explorer itself has been retired, making emulation modes like IE=EmulateIE7 or IE=9 pointless.
- Standards compliance. The WHATWG HTML living standard explicitly requires the content attribute value to be IE=edge when http-equiv="X-UA-Compatible" is used.
In practice, since all modern browsers use their latest rendering engine by default, this meta tag has little functional impact today. If your site no longer needs to support Internet Explorer at all, you can safely remove the tag entirely. If you choose to keep it — for example, in environments where legacy IE browsers might still access your site — ensure the value is exactly IE=edge.
Examples
Invalid: Using chrome=1 with IE=edge
This was a common pattern when Google Chrome Frame was active, but it now triggers a validation error:
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">Invalid: Using a legacy IE rendering mode
Forcing a specific IE version is no longer valid:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">Invalid: Specifying a particular IE version
<meta http-equiv="X-UA-Compatible" content="IE=9">Valid: Using IE=edge
The only accepted value is IE=edge:
<meta http-equiv="X-UA-Compatible" content="IE=edge">Valid: Removing the tag entirely
If you don’t need Internet Explorer compatibility, the simplest fix is to remove the meta tag altogether. A minimal valid document without it:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My Page</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>The HTML specification explicitly forbids numeric character references from expanding to certain control characters, and the carriage return (U+000D) is one of them. Even though you can type or in your markup, the spec defines this as a parse error. Browsers may handle it inconsistently — some will silently discard it, others may convert it to a different character — so relying on it leads to unpredictable behavior across environments.
The reason carriage return is singled out is rooted in how HTML normalizes line endings. During parsing, all carriage return characters (and carriage return + line feed pairs) are normalized to a single line feed (U+000A). Because the character is never preserved as-is, referencing it serves no practical purpose and is treated as an error. The WHATWG HTML Living Standard lists U+000D among the characters that must not appear as numeric character references.
Control characters in general are problematic in HTML text content. Most of them (U+0001 through U+001F, excluding tab, line feed, and form feed) are disallowed. The carriage return falls into this category because, after normalization, it effectively doesn’t exist in the parsed document.
How to fix it
- Remove it — In most cases, the reference is unnecessary. Simply delete it.
- Replace with — If you need a line break character reference (for example, in a title attribute or a pre element), use (LINE FEED), which is a permitted space character in HTML.
- Use <br> — If you need a visible line break in rendered content, use the <br> element instead of a character reference.
Examples
Incorrect: using a carriage return character reference
<p>First line Second line</p>This triggers the validation error because expands to the carriage return control character.
The same error occurs with hexadecimal notation:
<p>First line
Second line</p>Correct: using a line feed character reference
<p>First line Second line</p>The reference expands to LINE FEED (U+000A), which is allowed in HTML. Note that in normal flow, this renders as collapsible whitespace — it won’t produce a visible line break unless you’re inside a pre element or using CSS white-space: pre.
Correct: using <br> for a visible line break
<p>First line<br>Second line</p>If the goal is a visible line break in the rendered output, the <br> element is the standard and most reliable approach.
Correct: line break in an attribute value
Sometimes appears in attribute values where a newline is intended, such as in title tooltips:
<!-- Incorrect -->
<span title="Line one Line two">Hover me</span>
<!-- Correct -->
<span title="Line one Line two">Hover me</span>The reference is valid and some browsers will render it as a line break within tooltip text, though this behavior is not guaranteed across all browsers.
A numeric character reference is pointing to a C1 control code point (U+0080–U+009F), which is disallowed in HTML.
Numeric character references like &#nnn; or &#xhhhh; must resolve to valid Unicode characters.
The C1 control range U+0080–U+009F contains non-characters/control codes, so validators flag them.
Common causes: copying Windows-1252 bytes and encoding them as numeric references (e.g., — for an em dash) or misusing hex values (e.g., ’ for a right single quote).
In HTML, use the proper Unicode character, a valid named character reference, or the correct Unicode code point. Examples: use the actual “—” or — (U+2014), “’” or ’ (U+2019), “€” or € (U+20AC). If you must use numeric references, use the correct code points: — or — for em dash, not —; ’ or ’ for right single quote, not ’.
HTML Examples
Example that reproduces the issue
<!doctype html>
<html lang="en">
<head>
<title>Bad C1 NCR</title>
</head>
<body>
<p>Bad dash: —</p>
<p>Bad quote: ’</p>
</body>
</html>Fixed example
<!doctype html>
<html lang="en">
<head>
<title>Fixed NCRs</title>
</head>
<body>
<p>Good dash: — or — or —</p>
<p>Good quote: ’ or ’ or ’</p>
<p>Euro: € or € or €</p>
</body>
</html>The HTML living standard defines that scripts with type="module" are always fetched in parallel and evaluated after the document has been parsed, which is the same behavior that the defer attribute provides for classic scripts. Because this deferred execution is an inherent characteristic of module scripts, the spec explicitly forbids combining the two. Including both doesn’t change how the browser handles the script, but it signals a misunderstanding of how modules work and produces invalid HTML.
This validation error commonly arises when developers migrate classic scripts to ES modules. A classic script like <script defer src="app.js"></script> relies on the defer attribute to avoid blocking the parser. When converting to a module by adding type="module", it’s natural to leave defer in place — but it’s no longer needed or allowed.
It’s worth noting that the async attribute is valid on module scripts and does change their behavior. While defer is redundant because modules are already deferred, async overrides that default and causes the module to execute as soon as it and its dependencies have finished loading, rather than waiting for HTML parsing to complete.
How to Fix
Remove the defer attribute from any <script> element that has type="module". No other changes are needed — the loading and execution behavior will remain identical.
If you intentionally want the script to run as soon as possible (before parsing completes), use async instead of defer. But if you want the standard deferred behavior, simply omit both attributes and let the module default take effect.
Examples
❌ Incorrect: defer combined with type="module"
<script type="module" defer src="app.js"></script>The defer attribute is redundant here and causes a validation error.
✅ Correct: module script without defer
<script type="module" src="app.js"></script>Module scripts are deferred automatically, so this behaves exactly the same as the incorrect example above but is valid HTML.
✅ Correct: using async with a module (when needed)
<script type="module" async src="analytics.js"></script>Unlike defer, the async attribute is permitted on module scripts. It causes the module to execute as soon as it’s ready, without waiting for HTML parsing to finish.
✅ Correct: classic script with defer
<script defer src="app.js"></script>For classic (non-module) scripts, the defer attribute is valid and necessary if you want deferred execution.
The <script> element serves two distinct purposes in HTML: loading executable scripts and embedding non-executable data blocks. When the src attribute is present, the element is always being used to load an external script, so the type attribute must reflect a valid script type. Setting type to something like "text/html", "text/plain", or an invented value like "wrong" tells the browser this is not JavaScript, which means the external file referenced by src will be fetched but never executed — almost certainly not what the author intended.
The HTML specification restricts the allowed type values for <script src="..."> to three categories:
- An empty string (type=""): Treated the same as the default, which is JavaScript.
- A JavaScript MIME type: This includes text/javascript, application/javascript, and other legacy JavaScript MIME types. Since text/javascript is the default, specifying it is redundant.
- module: Indicates the script should be treated as a JavaScript module, enabling import/export syntax and deferred execution by default.
Any value outside these categories — such as text/html, application/json, or a made-up string — is invalid when src is present.
Why this matters
Broken functionality: A non-JavaScript type on a <script> with src prevents the browser from executing the loaded file. The script is effectively dead code that still costs a network request.
Standards compliance: The HTML living standard explicitly forbids this combination. Validators flag it because it almost always indicates a mistake — either the wrong type was applied, or the src attribute was added by accident.
Maintainability: Future developers reading the code may be confused about whether the script is supposed to execute or serve as an inert data block. Keeping markup valid makes intent clear.
How to fix it
- Remove the type attribute entirely. This is the best approach for classic JavaScript. The default behavior is text/javascript, so no type is needed.
- Use type="module" if the script uses ES module syntax (import/export).
- If you intended a data block (e.g., embedding JSON or a template), remove the src attribute and place the content inline inside the <script> element instead. Data blocks with non-JavaScript types cannot use src.
Examples
Invalid: non-JavaScript types with src
These all trigger the validation error because the type value is not a JavaScript MIME type, an empty string, or "module":
<script type="text/html" src="template.html"></script>
<script type="application/json" src="data.json"></script>
<script type="text/plain" src="app.js"></script>
<script type="wrong" src="app.js"></script>Valid: omitting the type attribute
The simplest and recommended fix for classic scripts — just drop type:
<script src="app.js"></script>Valid: using a JavaScript MIME type
This is valid but redundant, since text/javascript is already the default. The validator may suggest omitting it:
<script type="text/javascript" src="app.js"></script>Valid: using type="module"
Use this when the external script uses ES module syntax:
<script type="module" src="app.js"></script>Valid: using an empty type attribute
An empty string is treated as the default. It’s valid but unnecessary, and the validator may suggest removing it:
<script type="" src="app.js"></script>Valid: data blocks without src
If you need a non-JavaScript type for an inline data block, remove the src attribute and place the content directly inside the element:
<script type="application/json" id="config">
{
"apiUrl": "https://example.com/api",
"debug": false
}
</script>The HTML specification enforces this rule because a required <select> element needs options for the user to choose from. Without any <option> children, the element is semantically meaningless — it’s a dropdown with nothing to select, yet the form demands a selection before submission. This creates an impossible situation for the user and an ambiguous state for the browser.
This rule specifically applies when all three of these conditions are true:
- The required attribute is present.
- The multiple attribute is not present.
- The size attribute is either absent or set to 1 (the default for a single-selection <select>).
When multiple is set or size is greater than 1, the <select> behaves differently (as a list box rather than a dropdown), and the specification relaxes this constraint. But for the standard single-selection dropdown, at least one <option> is mandatory.
Why this matters
- Usability: A required dropdown with no options gives users no way to satisfy the form requirement, effectively blocking form submission entirely.
- Accessibility: Screen readers announce <select> elements along with their available options. An empty required dropdown creates a confusing experience for assistive technology users.
- Form validation: Browsers use the first <option> with an empty value as the placeholder. The built-in constraint validation for required selects relies on checking whether the selected option’s value is a non-empty string. Without any options, this validation behavior is undefined.
How the placeholder pattern works
The HTML specification defines a specific behavior for required single-selection dropdowns: the first <option> element, if it has an empty value attribute, acts as a placeholder. When the form is submitted with this placeholder still selected, browser validation will reject the submission because the value is empty. This is the standard pattern for prompting users to make a deliberate choice.
Examples
❌ Invalid: required <select> with no options
<label for="color">Pick a color:</label>
<select id="color" name="color" required>
</select>This triggers the validation error because there are no <option> elements inside the required <select>.
❌ Invalid: required <select> with only a group but no options
<label for="color">Pick a color:</label>
<select id="color" name="color" required>
<optgroup label="Colors">
</optgroup>
</select>An empty <optgroup> doesn’t satisfy the requirement. The <select> still needs at least one <option>.
✅ Valid: required <select> with a placeholder and options
<label for="color">Pick a color:</label>
<select id="color" name="color" required>
<option value="">--Select a color--</option>
<option value="red">Red</option>
<option value="green">Green</option>
<option value="blue">Blue</option>
</select>The first <option> has an empty value, so it serves as a placeholder. The browser will require the user to choose one of the other options before submitting the form.
✅ Valid: required <select> with multiple (rule does not apply)
<label for="colors">Pick one or more colors:</label>
<select id="colors" name="colors" required multiple>
</select>This does not trigger the error because the multiple attribute is present, which exempts the element from this particular rule. However, an empty multi-select is still poor UX and should generally be avoided.
✅ Valid: required <select> with size greater than 1 (rule does not apply)
<label for="colors">Pick a color:</label>
<select id="colors" name="colors" required size="4">
</select>When size is greater than 1, the element renders as a list box and the rule no longer applies. Again, while technically valid, an empty list box isn’t useful in practice.
✅ Valid: required <select> with grouped options
<label for="vehicle">Choose a vehicle:</label>
<select id="vehicle" name="vehicle" required>
<option value="">--Select a vehicle--</option>
<optgroup label="Cars">
<option value="sedan">Sedan</option>
<option value="suv">SUV</option>
</optgroup>
<optgroup label="Trucks">
<option value="pickup">Pickup</option>
<option value="semi">Semi</option>
</optgroup>
</select>Options inside <optgroup> elements count as child options of the <select>, so this is fully valid.
The HTML parser expects a slash inside a tag to signal the end of a self-closing (void) element, such as <br /> or <img />. When the parser encounters a / that isn’t immediately followed by >, it can’t interpret the tag correctly and raises this error. This can happen in several scenarios:
- A typo in an attribute name or value, such as accidentally typing a / instead of another character.
- An unquoted attribute value that contains a slash, like a URL path.
- A misplaced slash somewhere in the middle of a tag.
While browsers are generally forgiving and may still render the page, relying on error recovery leads to unpredictable behavior across different browsers. Fixing these issues ensures your markup is unambiguous, standards-compliant, and easier to maintain.
Examples
Stray slash in a tag (typo)
A common typo where a slash appears between attributes:
<!-- ❌ Slash not immediately followed by ">" -->
<input type="text" / name="username">Remove the stray slash:
<!-- ✅ Correct -->
<input type="text" name="username">Unquoted attribute value containing a slash
If an attribute value contains a / and isn’t wrapped in quotes, the parser sees the slash as part of the tag syntax rather than the value:
<!-- ❌ Unquoted value with slash confuses the parser -->
<img src=images/photo.jpg alt="Photo">Always quote attribute values, especially those containing slashes:
<!-- ✅ Correct: quoted attribute value -->
<img src="images/photo.jpg" alt="Photo">Slash in the wrong position for self-closing tags
Placing the slash before the final attribute instead of at the end of the tag:
<!-- ❌ Slash is not immediately before ">" -->
<img src="logo.png" / alt="Logo">Move the self-closing slash to the very end, or simply remove it (self-closing syntax is optional in HTML5 for void elements):
<!-- ✅ Correct: slash at the end -->
<img src="logo.png" alt="Logo" />
<!-- ✅ Also correct: no self-closing slash needed in HTML -->
<img src="logo.png" alt="Logo">Accidental double slash
Sometimes a self-closing tag ends up with an extra slash:
<!-- ❌ Double slash before ">" -->
<br //>Use a single slash or omit it entirely:
<!-- ✅ Correct -->
<br />
<!-- ✅ Also correct -->
<br>A <source> element inside a <picture> that is followed by another <source> or an <img> with srcset must include a media and/or type attribute.
The <source> element is used inside <picture> for responsive images, allowing different resources to be loaded based on conditions such as viewport width (media) or image format (type). According to the HTML standard, when multiple <source> elements are present (or a following <img> with srcset), each <source> must provide a media and/or type attribute so the browser can choose the appropriate resource based on those hints.
Without media or type, the browser cannot distinguish when to use each source, which can lead to validation errors and unexpected rendering behavior.
Incorrect example (causes the validator error):
<picture>
<source srcset="image1.webp">
<source srcset="image2.jpg">
<img alt="" src="fallback.jpg" srcset="fallback2x.jpg 2x">
</picture>Correct examples (fixing the error):
<picture>
<source srcset="image1.webp" type="image/webp">
<source srcset="image2.jpg" type="image/jpeg">
<img alt="" src="fallback.jpg" srcset="fallback2x.jpg 2x">
</picture>or
<picture>
<source srcset="image-small.jpg" media="(max-width: 600px)">
<source srcset="image-large.jpg" media="(min-width: 601px)">
<img alt="" src="fallback.jpg" srcset="fallback2x.jpg 2x">
</picture>By specifying the media and/or type attributes for each <source>, you satisfy the HTML standard and resolve the W3C validator issue.
In HTML, the structure of a <table> is implicitly defined by its rows and columns. The first <tr> in a table (or table section like <thead>, <tbody>, or <tfoot>) establishes the expected column count for the entire table. When a subsequent row contains more cells than the first row, the validator raises this error because the table’s column grid becomes inconsistent.
Browsers will still attempt to render mismatched tables, but the results can be unpredictable and problematic. Screen readers and other assistive technologies rely on a well-formed table grid to correctly associate data cells with their headers. An inconsistent column count can cause these tools to misread or skip content, making the table inaccessible to users who depend on them. Additionally, inconsistent tables are harder to style with CSS and can lead to unexpected layout shifts.
There are several common causes for this issue:
- Missing cells in the first row — The first row has fewer <td> or <th> elements than subsequent rows.
- Forgotten colspan — A cell in the first row should span multiple columns but is missing a colspan attribute.
- Extra cells in later rows — A row further down the table has more cells than intended.
- Mismatched colspan arithmetic — The sum of cells and their colspan values doesn’t add up consistently across rows.
To fix this, review every row in the table and ensure the total column count (accounting for colspan and rowspan attributes) is the same for each row.
Examples
Incorrect: second row has more columns than the first
The first row defines 1 column, but the second row has 2 columns.
<table>
<tr>
<td>Liza</td>
</tr>
<tr>
<td>Jimmy</td>
<td>14</td>
</tr>
</table>Fixed: add missing cells to the first row
Make both rows have 2 columns by adding a header or data cell to the first row.
<table>
<tr>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>Jimmy</td>
<td>14</td>
</tr>
</table>Fixed: use colspan if the first row intentionally spans the full width
If the first row is meant to be a single spanning header, use colspan to match the total column count.
<table>
<tr>
<th colspan="2">Student Info</th>
</tr>
<tr>
<td>Jimmy</td>
<td>14</td>
</tr>
</table>Incorrect: later row exceeds column count with extra cells
<table>
<tr>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>Liza</td>
<td>12</td>
<td>Extra cell</td>
</tr>
</table>Fixed: remove the extra cell or expand the header row
<table>
<tr>
<th>Name</th>
<th>Age</th>
<th>Notes</th>
</tr>
<tr>
<td>Liza</td>
<td>12</td>
<td>Extra cell</td>
</tr>
</table>Incorrect: colspan mismatch causes inconsistent totals
The first row spans 3 columns total (1 + colspan="2"), but the second row has 4 cells.
<table>
<tr>
<th>Name</th>
<th colspan="2">Contact</th>
</tr>
<tr>
<td>Liza</td>
<td>liza@example.com</td>
<td>555-0100</td>
<td>Room 4</td>
</tr>
</table>Fixed: adjust colspan or cell count so all rows match
<table>
<tr>
<th>Name</th>
<th colspan="3">Contact & Location</th>
</tr>
<tr>
<td>Liza</td>
<td>liza@example.com</td>
<td>555-0100</td>
<td>Room 4</td>
</tr>
</table>When debugging this issue, count the effective columns for each row by adding up the number of cells plus any additional columns contributed by colspan values (a colspan="3" cell counts as 3 columns). Every row in the table must produce the same total.
HTML tables establish their column count based on the first row. When subsequent rows have fewer <td> or <th> cells than that initial row defines, the table structure becomes invalid. Browsers will typically render these tables by leaving blank space where the missing cells should be, but the underlying markup is malformed.
This matters for several important reasons. Screen readers and other assistive technologies rely on a consistent table structure to navigate cells and associate data with the correct headers. When cells are missing, users who depend on these tools may receive confusing or incorrect information. Additionally, inconsistent row widths can lead to unpredictable layout behavior across different browsers and make your table markup harder to maintain.
When counting columns, remember that the colspan attribute contributes to the total. A single <td colspan="3"> counts as three columns, not one. So if your first row has two <td> elements and one of them has colspan="2", the table is three columns wide, and every other row must also account for three columns.
How to Fix
There are several approaches depending on your intent:
- Add the missing cells — If data was accidentally omitted, add the appropriate <td> or <th> elements to complete the row.
- Use colspan — If a cell should intentionally span multiple columns, use the colspan attribute so the total column count matches.
- Add empty cells — If a cell simply has no content, include an empty <td></td> to maintain the structure.
Examples
❌ Row with fewer columns than the first row
The first row establishes a 3-column table, but the second row only has 2 cells:
<table>
<tr>
<td>Name</td>
<td>Role</td>
<td>Department</td>
</tr>
<tr>
<td>Alice</td>
<td>Engineer</td>
</tr>
</table>✅ Fix by adding the missing cell
<table>
<tr>
<td>Name</td>
<td>Role</td>
<td>Department</td>
</tr>
<tr>
<td>Alice</td>
<td>Engineer</td>
<td>Product</td>
</tr>
</table>✅ Fix by using colspan to span remaining columns
If the second row intentionally has fewer logical cells, use colspan so the total still matches:
<table>
<tr>
<td>Name</td>
<td>Role</td>
<td>Department</td>
</tr>
<tr>
<td>Alice</td>
<td colspan="2">Engineer — General</td>
</tr>
</table>✅ Fix by adding an empty cell
If there’s simply no data for that column, include an empty cell:
<table>
<tr>
<td>Name</td>
<td>Role</td>
<td>Department</td>
</tr>
<tr>
<td>Alice</td>
<td>Engineer</td>
<td></td>
</tr>
</table>❌ Mismatch caused by colspan in the first row
Be careful when the first row uses colspan, as it increases the effective column count:
<table>
<tr>
<td colspan="2">Full Name</td>
<td>Role</td>
</tr>
<tr>
<td>Alice</td>
<td>Engineer</td>
</tr>
</table>Here the first row spans 3 columns (2 + 1), but the second row only has 2 cells.
✅ Fix by matching the full column count
<table>
<tr>
<td colspan="2">Full Name</td>
<td>Role</td>
</tr>
<tr>
<td>Alice</td>
<td>Smith</td>
<td>Engineer</td>
</tr>
</table>When a browser encounters a document, the doctype declaration is the first thing it reads to determine which rendering mode to use. There are three modes: quirks mode, almost standards mode, and full standards mode. Almost standards mode was introduced as a transitional step — it renders pages mostly according to standards but retains a few legacy behaviors, particularly around how images inside table cells are laid out. Doctypes that trigger this mode include:
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
These doctypes were common during the XHTML and HTML 4 era but are now considered obsolete. The W3C HTML Validator (Nu HTML Checker) is designed for HTML5 documents and expects the simple <!DOCTYPE html> declaration.
Why this matters
- Standards compliance: The HTML Living Standard (maintained by WHATWG) specifies <!DOCTYPE html> as the only valid doctype. Using anything else means your document does not conform to the current standard.
- Rendering consistency: While almost standards mode is close to full standards mode, the subtle differences — especially around vertical sizing of table cell images — can lead to unexpected layout behavior across browsers.
- Future-proofing: Legacy doctypes tie your pages to outdated specifications. Modern tooling, linters, and validators all expect HTML5, and maintaining an old doctype can mask other issues.
- Simplicity: The HTML5 doctype is short, easy to remember, and case-insensitive. There’s no reason to use a longer, more complex declaration.
How to fix it
Replace the legacy doctype on the very first line of your HTML document with <!DOCTYPE html>. No public identifier, no system identifier, and no DTD URL is needed. After making the change, review your page for any layout shifts — in most cases there will be none, but pages that relied on the subtle almost-standards-mode behavior around images in table cells may need a small CSS adjustment (such as setting img { display: block; } or img { vertical-align: bottom; } on affected images).
Examples
❌ Legacy doctype triggering almost standards mode
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>My Page</title>
</head>
<body>
<h1>Hello, world!</h1>
</body>
</html>❌ HTML 4.01 Transitional doctype
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Hello, world!</h1>
</body>
</html>✅ Correct HTML5 doctype
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My Page</title>
</head>
<body>
<h1>Hello, world!</h1>
</body>
</html>The HTML5 doctype is the shortest possible doctype that triggers full standards mode in all modern browsers. It works regardless of case (<!DOCTYPE html>, <!doctype html>, or <!Doctype Html> are all equivalent), though lowercase or the conventional mixed-case form shown above is recommended for consistency.
An a element with both an href attribute and aria-disabled="true" is invalid; either remove aria-disabled or the href attribute.
The aria-disabled attribute is used for interactive elements to indicate that the element is perceivable as disabled by assistive technologies. However, using aria-disabled="true" in combination with an href attribute on an a element is not valid, because the link remains actionable for both user agents and assistive devices. Instead, if a link should appear disabled, you should remove the href attribute, use CSS for styling, and optionally use aria-disabled="true". If you need the element to always act as a link, avoid aria-disabled and control user access through application logic.
Incorrect:
<a href="page.html" aria-disabled="true">Visit Page</a>Correct—Option 1: Remove aria-disabled, keep link active
<a href="page.html">Visit Page</a>Correct—Option 2: Remove href, use aria-disabled, for non-actionable item
<a aria-disabled="true" tabindex="-1" style="pointer-events: none; color: gray;">Visit Page</a>In the second correct example, setting tabindex="-1" prevents keyboard navigation, and pointer-events: none; makes the link unclickable, while aria-disabled="true" makes the disabled state accessible.
A role="cell" element must be a child of an element with role="row" for correct ARIA relationships.
According to the ARIA specification, role="cell" should be directly contained within a parent with role="row", which itself should usually be inside an element with role="rowgroup" or role="table". This structure allows assistive technologies to interpret your table semantics correctly.
Correct Structure Example:
<div role="table">
<div role="row">
<div role="cell">Row 1, Cell 1</div>
<div role="cell">Row 1, Cell 2</div>
</div>
<div role="row">
<div role="cell">Row 2, Cell 1</div>
<div role="cell">Row 2, Cell 2</div>
</div>
</div>Incorrect Structure Example (missing row):
<div role="table">
<div role="cell">Cell without row</div>
</div>
How to fix:
Wrap any element with role="cell" inside an element with role="row". This ensures both validity and proper accessibility support.
A role="columnheader" element must be a child of or associated with a role="row" element.
In HTML, ARIA roles such as columnheader are used to improve accessibility for assistive technologies. According to the ARIA specification, a columnheader role should appear inside an element with role="row", which itself should be inside an element with role="table" or role="grid". This structure mimics how native tables are constructed with <th> elements inside <tr>s.
Correct structure:
- role="table" or role="grid" contains one or more elements with role="row".
- Each role="row" contains one or more elements with role="columnheader" (or role="cell").
Example using ARIA roles for a simple table:
<div role="table" aria-label="Sample Table">
<div role="row">
<div role="columnheader">Name</div>
<div role="columnheader">Age</div>
</div>
<div role="row">
<div role="cell">Alice</div>
<div role="cell">30</div>
</div>
</div>
Best practice:
Whenever possible, use native table elements, which have built-in roles and accessibility, reducing the chance of ARIA misuse.
Example using native table markup:
<table>
<tr>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>Alice</td>
<td>30</td>
</tr>
</table>Ensure that any element with role="columnheader" is always contained within a parent with role="row". Avoid placing role="columnheader" directly inside a container without the appropriate role="row" ancestor.
The WAI-ARIA specification defines strict ownership requirements for certain roles. The listitem role is one such role — it must be “owned by” an element with role="list" or role="group". “Owned by” means the listitem must be either a direct DOM child of the owning element, or explicitly associated with it via the aria-owns attribute.
This matters because screen readers and other assistive technologies rely on the accessibility tree to convey structure to users. When a screen reader encounters a properly structured list, it announces something like “list, 3 items” and lets the user navigate between items. Without the parent role="list", the individual items lose their list context — users won’t know how many items exist, where the list begins and ends, or that the items are related at all.
In most cases, the simplest and most robust fix is to use native HTML list elements (<ul> or <ol> with <li> children) instead of ARIA roles. Native elements have built-in semantics that don’t require additional attributes. Only use ARIA roles when native elements aren’t feasible — for example, when building a custom component where the visual layout prevents using standard list markup.
Examples
Incorrect: listitem without a parent list
These listitem elements are not contained within a role="list" or role="group" parent, so the validator reports an error.
<div role="listitem">Apples</div>
<div role="listitem">Bananas</div>
<div role="listitem">Cherries</div>Correct: wrapping items in role="list"
Adding a parent container with role="list" establishes the required ownership relationship.
<div role="list">
<div role="listitem">Apples</div>
<div role="listitem">Bananas</div>
<div role="listitem">Cherries</div>
</div>Correct: using native HTML list elements
Native <ul> and <li> elements implicitly carry the list and listitem roles without any ARIA attributes. This is the preferred approach.
<ul>
<li>Apples</li>
<li>Bananas</li>
<li>Cherries</li>
</ul>Correct: using role="group" for nested sublists
The role="group" container is appropriate for grouping a subset of list items within a larger list, such as a nested sublist.
<div role="list">
<div role="listitem">Fruits
<div role="group">
<div role="listitem">Apples</div>
<div role="listitem">Bananas</div>
</div>
</div>
<div role="listitem">Vegetables
<div role="group">
<div role="listitem">Carrots</div>
<div role="listitem">Peas</div>
</div>
</div>
</div>Note that role="group" should itself be nested inside a role="list" — it doesn’t replace the top-level list container, but rather serves as an intermediate grouping mechanism within one.
Correct: using aria-owns for non-descendant ownership
If the DOM structure prevents you from nesting the items directly inside the list container, you can use aria-owns to establish the relationship programmatically.
<div role="list" aria-owns="item-1 item-2 item-3"></div>
<!-- These items live elsewhere in the DOM -->
<div role="listitem" id="item-1">Apples</div>
<div role="listitem" id="item-2">Bananas</div>
<div role="listitem" id="item-3">Cherries</div>This approach should be used sparingly, as it can create confusion if the visual order doesn’t match the accessibility tree order. Whenever possible, restructure your HTML so the items are actual descendants of the list container.
Ready to validate your sites?
Start your free trial today.