HTML Guides

End tag X seen, but there were open elements.

unexpected end tag

HTML follows a strict nesting model where elements must be closed in last-in, first-out (LIFO) order. Think of it like stacking boxes: you must close the innermost box before you can close the one containing it. When you write </li> but a <span> inside that <li> is still open, the browser sees a conflict — you're trying to close the outer element while an inner element is dangling.

This error typically occurs due to one of these situations:

A missing closing tag for a nested element (e.g., forgetting </span> inside a <li>).
Misordered closing tags where you accidentally close elements in the wrong sequence.
Typos in tag names where the intended closing tag doesn't match the opening tag, leaving the real element unclosed.

While browsers use error-recovery algorithms to guess what you meant, different browsers may handle malformed nesting differently. This can lead to inconsistent rendering, broken styles, and unexpected DOM structures. Screen readers and other assistive technologies rely on a well-formed DOM tree, so broken nesting can also cause accessibility issues. Keeping your HTML properly nested ensures predictable behavior across all browsers and tools.

How to fix it

Locate the line referenced in the validator error. It will tell you which closing tag was seen and which elements were still open.
Trace backward from the closing tag to find the unclosed element.
Add the missing closing tag in the correct position, or reorder closing tags so they mirror the opening tags in reverse.
Re-validate to confirm the fix, since one nesting error can cascade into multiple warnings.

Examples

❌ Missing closing tag for a nested element

<ul>

</ul>

The <span> inside the first <li> is never closed. The validator sees </li> but <span> is still open.

✅ Fixed: close the inner element first

<ul>

</ul>

❌ Misordered closing tags

<p>This is <strong><em>important</strong></em> text.</p>

Here </strong> appears before </em>, but <em> was opened inside <strong>, so <em> must close first.

✅ Fixed: close tags in reverse order

<p>This is <strong><em>important</em></strong> text.</p>

❌ Multiple levels of broken nesting

<div>

<p>Hello <ahref="/">world</p>

</section>

</div>

The <a> element is never closed. The </p> tag is encountered while <a> is still open.

✅ Fixed: close the anchor before the paragraph

<div>

<p>Hello <ahref="/">world</a></p>

</section>

</div>

❌ Typo in a closing tag causing a mismatch

<p>Click <ahref="/help">here</b> for help.</p>

The closing </b> doesn't match the opening <a>, so the <a> element remains open when </p> is reached.

✅ Fixed: use the correct closing tag

<p>Click <ahref="/help">here</a> for help.</p>

A helpful way to avoid this error is to visualize your HTML as an outline — every level of indentation represents a nesting level, and closing tags should "unwind" in exact reverse order. Many code editors also offer bracket and tag matching features that highlight mismatched or unclosed tags in real time.

Forbidden code point X

The HTML specification explicitly forbids certain Unicode code points from appearing anywhere in an HTML document. These include most ASCII control characters (such as U+0000 NULL, U+0008 BACKSPACE, or U+000B VERTICAL TAB), as well as Unicode noncharacters like U+FFFE, U+FFFF, and the range U+FDD0 to U+FDEF. When the W3C validator encounters one of these code points, it reports the error "Forbidden code point" followed by the specific value.

These characters are forbidden because they have no defined meaning in HTML and can cause unpredictable behavior across browsers and platforms. Some may be silently dropped, others may produce rendering glitches, and some could interfere with parsing. Screen readers and other assistive technologies may also behave erratically when encountering these characters, making this an accessibility concern as well.

How forbidden characters get into your code

Copy-pasting from external sources like word processors, PDFs, or databases that embed invisible control characters.
Faulty text editors or build tools that introduce stray bytes during file processing.
Incorrect character encoding where byte sequences are misinterpreted, resulting in forbidden code points.
Programmatic content generation where strings aren't properly sanitized before being inserted into HTML.

How to fix it

Identify the character and its location. The validator message includes the code point (e.g., U+000B) and the line number. Use a text editor that can show invisible characters (such as VS Code with the "Render Whitespace" or "Render Control Characters" setting enabled, or a hex editor).
Remove or replace the character. In most cases, the forbidden character serves no purpose and can simply be deleted. If it was standing in for a space or line break, replace it with the appropriate standard character.
Sanitize content at the source. If your HTML is generated dynamically, strip forbidden code points from strings before outputting them. In JavaScript, you can use a regular expression to remove them.

// Remove common forbidden code points

text=text.replace(/[\x00-\x08\x0B\x0E-\x1F\x7F\uFDD0-\uFDEF\uFFFE\uFFFF]/g,'');

Examples

Incorrect — contains a forbidden control character

In this example, a vertical tab character (U+000B) is embedded between "Hello" and "World." It is invisible in most editors but the validator will flag it.

<p>Hello␋World</p>

Correct — forbidden character removed

<p>Hello World</p>

Incorrect — NULL character in an attribute value

A U+0000 NULL character may appear inside an attribute, often from programmatic output.

<divtitle="SomeText">Content</div>

Correct — NULL character removed from attribute

<divtitle="SomeText">Content</div>

Allowed control characters

Not all control characters are forbidden. The following are explicitly permitted in HTML:

U+0009 — Horizontal tab (regular tab character)
U+000A — Line feed (newline)
U+000D — Carriage return

<pre>Line one

Line two with a tab</pre>

This is valid because it uses only standard whitespace characters (U+000A for the newline and U+0009 for the tab).

Garbage after “</”.

When the parser sees </, it expects the start of an end tag — specifically, a sequence like </tagname> where the tag name immediately follows the slash with no spaces, invalid characters, or other unexpected content before the closing >. Anything else is considered "garbage" because it doesn't conform to the HTML syntax rules for end tags.

This error matters for several reasons. First, browsers enter error-recovery mode when they encounter malformed markup, and different browsers may recover differently, leading to inconsistent rendering. Second, assistive technologies like screen readers rely on a well-formed DOM tree, so malformed tags can disrupt accessibility. Third, what seems like a minor typo can cascade into larger parsing problems — the parser may misinterpret the document structure, causing elements to nest incorrectly or content to disappear.

Here are the most common causes of this error:

A space between the slash and the tag name: </ div> instead of </div>.
Trying to close a void element: </br>, </img>, or </input>. Void elements must not have end tags in HTML.
Accidental or malformed sequences: </--, </>, or </3 appearing in content.
Displaying markup as text without escaping: Writing </div> in a paragraph when you meant to show it literally, instead of using </div>.
Typos or leftover characters: </p>extra or </p.> where stray characters follow the tag name.

To fix this error, inspect the line indicated by the validator and determine what you intended. If it should be a closing tag, correct the syntax. If it should be visible text, escape the < as <. If it's an attempt to close a void element, simply remove the end tag entirely.

Examples

Space inside the end tag

A space between </ and the tag name triggers the error:

<p>Hello world.</p>

<p>Hello world.</p>

Trying to close a void element

Void elements like br, hr, img, and input must not have end tags:

Unescaped markup in text content

If you want to display HTML code as readable text, escape the angle brackets:

<p>To close a paragraph, use </p> at the end.</p>

<p>To close a paragraph, use <code></p></code> at the end.</p>

Accidental or malformed sequences

Stray characters after </ that don't form a valid tag name:

Full document example

<!doctype html>

<htmllang="en">

<head>

<title>Example</title>

</head>

<body>

<p>This has a bad closing tag.</p>

</body>

</html>

<!doctype html>

<htmllang="en">

<head>

<title>Example</title>

</head>

<body>

<p>This has a correct closing tag.</p>

</body>

</html>

Heading cannot be a child of another heading.

According to the HTML specification, heading elements (h1–h6) have a content model of "phrasing content," which means they can only contain inline-level elements like span, strong, em, a, and text nodes. Other heading elements are not phrasing content — they are flow content — so placing one heading inside another is invalid HTML.

This matters for several reasons. Screen readers and other assistive technologies rely on a well-formed heading hierarchy to help users navigate a page. When headings are nested inside each other, the document outline becomes broken and confusing, making it harder for users to understand the structure of the content. Browsers may also attempt to "fix" the invalid markup by auto-closing the outer heading before starting the inner one, which can produce unexpected rendering and DOM structures that differ from what you intended.

There are two common causes of this error:

Intentionally nesting headings for styling. Developers sometimes nest an h2 inside an h1 hoping to create a visual "main heading + subtitle" pattern. This is invalid. Instead, use separate heading elements or use a span or p element for the subtitle.
A missing or malformed closing tag. If you accidentally write <h3> instead of </h3> for a closing tag, the browser sees two opening h3 tags in a row. The first heading is never properly closed, and the second heading appears to be nested inside it.

Examples

❌ Heading nested inside another heading

<h1>Main heading

<h2>Sub heading</h2>

</h1>

The h2 is a child of the h1, which is not allowed. To create a heading with a subtitle, use separate elements:

✅ Headings as siblings

<h1>Main heading</h1>

<h2>Sub heading</h2>

Or, if the subtitle should be part of a sectioned document structure:

<main>

<h1>Main heading</h1>

<h2>Section heading</h2>

<p>Paragraph content</p>

</section>

</main>

❌ Missing closing slash causes nesting

A very common typo is forgetting the / in the closing tag:

<h3>Meet the Feebles<h3>

<h3>Bad Taste<h3>

Here, <h3>Meet the Feebles<h3> opens a second h3 instead of closing the first one. The validator sees the second h3 as a child of the first. The same problem cascades to subsequent headings.

✅ Properly closed heading tags

<h3>Meet the Feebles</h3>

<h3>Bad Taste</h3>

❌ Using nested headings for visual hierarchy inside a heading

<h1>

Our Company

<h3>Established 1999</h3>

</h1>

✅ Using a `span` for supplementary text within a heading

<h1>

Our Company

<spanclass="subtitle">Established 1999</span>

</h1>

You can then style the .subtitle class with CSS to achieve the desired visual appearance — for example, displaying it on a new line with a smaller font size:

.subtitle{

display: block;

font-size:0.5em;

font-weight: normal;

}

✅ Using the `hgroup` element

The hgroup element is specifically designed for grouping a heading with related content like subtitles:

<h1>Our Company</h1>

<p>Established 1999</p>

</hgroup>

This keeps the heading hierarchy clean while semantically associating the subtitle with the heading. The hgroup element is supported in the current HTML living standard and works well with assistive technologies.

HTML start tag “img” in a foreign namespace context.

When the HTML parser encounters an <svg> or <math> tag, it switches from the HTML namespace into a foreign namespace (SVG or MathML, respectively). Inside these foreign contexts, only elements defined by those specifications are valid. The HTML <img> element does not exist in the SVG or MathML namespaces, so placing it there causes a parsing conflict and triggers the W3C validator error: "HTML start tag img in a foreign namespace context."

This matters for several reasons. Browsers handle this situation inconsistently — some may break out of the foreign namespace to render the <img>, while others may ignore it entirely or produce unexpected layout results. This inconsistency means your page may look correct in one browser but be broken in another. Beyond rendering issues, assistive technologies rely on proper namespace boundaries to interpret content. An <img> in the wrong namespace may lose its accessibility semantics, meaning the alt text could go unannounced to screen reader users.

How to fix it

The fix depends on which foreign namespace context contains the <img>:

Inside <svg>: Replace <img> with the SVG <image> element. Note that SVG's <image> uses the href attribute (not src) and requires x, y, width, and height attributes for positioning and sizing. Unfortunately, SVG's <image> element does not support an alt attribute directly — use a <title> child element or aria-label to provide an accessible name.

Inside <math>: Move the <img> outside the <math> element entirely, or place it inside an <mtext> element. The <mtext> element in MathML is designed to hold text content and, per the HTML parsing rules, can contain embedded HTML elements.

Examples

Incorrect: `<img>` inside `<svg>`

<svgwidth="200"height="200">

<imgsrc="diagram.png"alt="A diagram"width="200"height="200">

</svg>

Correct: using SVG `<image>` element

<svgwidth="200"height="200"role="img"aria-label="A diagram">

<imagehref="diagram.png"x="0"y="0"width="200"height="200"/>

</svg>

Correct: with an accessible name via `<title>`

<svgwidth="200"height="200"role="img"aria-labelledby="diagram-title">

<titleid="diagram-title">A diagram</title>

<imagehref="diagram.png"x="0"y="0"width="200"height="200"/>

</svg>

Incorrect: `<img>` inside `<math>`

<math>

<imgsrc="equation.png"alt="x squared plus one">

</math>

Correct: `<img>` inside `<mtext>` within `<math>`

<math>

<mtext>

<imgsrc="equation.png"alt="x squared plus one">

</mtext>

</math>

Correct: `<img>` moved outside `<math>`

<imgsrc="equation.png"alt="x squared plus one">

Incorrect: mixed HTML content inside `<svg>`

<svgwidth="300"height="150">

<rectwidth="300"height="150"fill="#eee"/>

<imgsrc="icon.png"alt="Icon"width="32"height="32">

<textx="50"y="80">Hello</text>

</svg>

Correct: using `<image>` alongside other SVG elements

<svgwidth="300"height="150">

<rectwidth="300"height="150"fill="#eee"/>

<imagehref="icon.png"x="10"y="10"width="32"height="32"aria-label="Icon"/>

<textx="50"y="80">Hello</text>

</svg>

If you need to place HTML content alongside or on top of an SVG, consider using the <foreignObject> SVG element, which explicitly creates an HTML namespace context within SVG:

<svgwidth="300"height="150">

<rectwidth="300"height="150"fill="#eee"/>

<foreignObjectx="10"y="10"width="100"height="100">

<imgsrc="icon.png"alt="Icon"width="32"height="32">

</foreignObject>

</svg>

The <foreignObject> approach is especially useful when you need full HTML capabilities — such as alt text on <img>, form controls, or rich text — inside an SVG graphic.

HTML start tag “span” in a foreign namespace context.

HTTP request failed: null

network error

HTTP resource not retrievable. The HTTP status from the remote server was: 202.

html
202

An HTTP 202 Accepted status code indicates that the server has received and acknowledged the request, but the processing is not yet complete. This is commonly used for asynchronous operations — the server queues the work and responds immediately to let the client know the request was accepted without making the client wait. While this is perfectly valid for APIs and background job systems, it's not appropriate for serving HTML documents, stylesheets, scripts, or other resources that the browser (or validator) needs to read immediately.

The W3C HTML Validator works by fetching your page and any linked resources (CSS files, images, scripts, etc.) over HTTP. It expects a 200 OK response with the full content in the response body. When it receives a 202 Accepted, the body may be empty, incomplete, or contain a placeholder — none of which can be meaningfully validated. This results in the validator aborting its check for that resource and reporting the error.

Common Causes

Server-side processing delays: Your web server or application framework is deferring content generation to a background process and returning 202 as an interim response.
Asynchronous or queued endpoints: The URL points to an API-style endpoint that triggers a job rather than serving content directly.
CDN or proxy misconfiguration: A content delivery network or reverse proxy in front of your server is returning 202 while it fetches or generates the resource from the origin.
On-demand static site generation: Some platforms generate pages on first request and return 202 until the build is complete (e.g., incremental static regeneration that hasn't cached the page yet).

How to Fix

The core fix is ensuring that the URL you submit to the validator responds with a 200 OK status and delivers the full resource content in the response body. Here are specific steps:

Check your server configuration. Make sure your web server or application returns 200 OK for HTML pages and static assets. If background processing is needed, it should happen before the response is sent, or the result should be cached and served directly on subsequent requests.
Avoid validating asynchronous endpoints. If a URL is designed to trigger background work (like a webhook or task queue), it's not a validatable HTML resource. Only submit URLs that serve complete HTML documents.
Pre-warm cached content. If your hosting platform uses on-demand generation, visit the URL in a browser first to trigger the build, then validate it once the page is fully generated and cached.
Inspect the response headers. Use browser developer tools or a command-line tool like curl -I <url> to verify the status code your server actually returns. Look for the HTTP/1.1 202 Accepted line and trace why it's being sent.

Examples

Incorrect server behavior (returns 202)

In this conceptual example, the server responds with 202 for an HTML page, which prevents the validator from checking it:

HTTP/1.1 202 Accepted

Content-Type: text/html

If you're using a Node.js/Express server, this kind of code would cause the problem:

app.get('/page',(req,res)=>{

res.status(202).send('<p>Processing...</p>');

// Background work happens later

});

Correct server behavior (returns 200)

The server should respond with 200 OK and the complete HTML content:

HTTP/1.1200OK

Content-Type:text/html;charset=utf-8

<!DOCTYPEhtml>

<htmllang="en">

<head>

</head>

<body>

<h1>Welcome</h1>

<p>This page is fully rendered and ready to validate.</p>

</body>

</html>

The equivalent fix in a Node.js/Express server:

app.get('/page',(req,res)=>{

consthtml=renderPage();// Generate full content synchronously or await it

res.status(200).send(html);

});

Verifying the status code with curl

You can check what status code a URL returns before submitting it to the validator:

curl-Ihttps://example.com/page

Look for HTTP/1.1 200 OK (or HTTP/2 200) in the first line of the output. If you see 202 Accepted, investigate your server configuration before attempting validation.

HTTP resource not retrievable. The HTTP status from the remote server was: 403.

html
403

The W3C HTML Validator doesn't just parse your markup—it also attempts to retrieve external resources referenced in elements like <link>, <script>, <img>, and <iframe>. When a server returns a 403 status code, it's telling the validator "you are not authorized to access this resource." The validator then reports this as an informational message because it cannot fully validate the referenced content.

Common Causes

Several server-side configurations can trigger this issue:

Hotlink protection — Many servers and CDNs block requests that don't originate from an approved domain. Since the validator's requests come from validator.w3.org, they get rejected.
IP-based restrictions or firewalls — The remote server may restrict access to specific IP ranges, blocking the validator's servers.
User-Agent filtering — Some servers reject requests from bots or non-browser User-Agents, which includes the validator.
Authentication requirements — The resource may sit behind a login wall or require API keys or tokens.
Geographic restrictions — The server may use geo-blocking that prevents access from the validator's location.

Why This Matters

While this is typically an informational warning rather than a hard HTML error, it has practical implications:

Incomplete validation — The validator can't check the referenced resource for errors. For example, if a CSS file returns 403, the validator can't verify the stylesheet for issues that might affect your page.
Potential broken references — A 403 may indicate that the resource URL is incorrect or outdated, meaning real users could also experience issues depending on their browser or network configuration.
Accessibility and reliability concerns — If the resource is intermittently blocked, some users may not receive critical stylesheets or scripts, leading to a degraded experience.

How to Fix It

Verify the URL is correct — Double-check for typos or outdated paths.
Host resources on your own server — Download the resource and serve it locally or from a CDN you control.
Use a CDN that permits open access — Popular open CDNs like cdnjs, jsDelivr, or unpkg are designed to allow unrestricted access.
Configure the remote server — If you control the server hosting the resource, whitelist the validator's User-Agent or allow requests from validator.w3.org.
Remove unnecessary references — If the resource isn't actually needed, remove the element entirely.

Examples

Resource blocked by remote server

This references a stylesheet on a server that returns 403 to the validator:

<linkrel="stylesheet"href="https://restricted-server.example.com/styles/main.css">

Fixed: Host the resource locally

Download the stylesheet and serve it from your own domain:

<linkrel="stylesheet"href="/css/main.css">

Fixed: Use a publicly accessible CDN

Switch to a well-known open CDN that doesn't block external requests:

<linkrel="stylesheet"href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css">

Script blocked by hotlink protection

<scriptsrc="https://protected-site.example.com/js/library.min.js"></script>

Fixed: Use a reliable public source

<scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.21/lodash.min.js"></script>

Image blocked by access restrictions

<imgsrc="https://private-cdn.example.com/photos/banner.jpg"alt="Welcome banner">

Fixed: Host the image yourself

<imgsrc="/images/banner.jpg"alt="Welcome banner">

Keep in mind that this warning only appears during validation—it doesn't necessarily mean your end users are experiencing the same 403 error. Browsers send different headers (including cookies, referrers, and User-Agent strings) than the validator does, so the resource may load fine for visitors. However, it's still good practice to ensure your referenced resources are reliably accessible and that validation can complete fully.

HTTP resource not retrievable. The HTTP status from the remote server was: 404.

This error is not about your HTML syntax being invalid — it's about a broken reference. The W3C Validator follows URLs it encounters in your markup (or a URL you submit directly for validation) and checks whether the server can actually deliver the resource. When the remote server returns an HTTP 404 (Not Found) response, the validator flags the issue because the referenced resource is missing or unreachable.

There are several common causes for this error:

Typos in the URL — A misspelled filename, path, or domain name.
Moved or deleted resources — The file existed at one point but has since been removed or relocated.
Case sensitivity — Many web servers treat Image.png and image.png as different files. A mismatch in letter casing can produce a 404.
Incorrect relative paths — A relative URL that resolves differently than expected based on the document's location.
External resources no longer available — Third-party CDNs or hosted files that have been taken down.

This matters because broken references degrade the user experience. Missing stylesheets can leave a page unstyled, missing scripts can break functionality, and missing images display broken image icons. Search engines also penalize pages with excessive broken links, and screen readers may announce confusing or unhelpful content when resources fail to load.

How to Fix It

Check the URL carefully. Copy the full URL from your HTML, paste it into a browser, and see if it loads. If it returns a 404 page, the URL is wrong.
Verify the file exists on the server. If you control the server, confirm the file is in the expected directory with the exact filename and extension.
Fix case sensitivity issues. Ensure the capitalization in your URL matches the actual filename on the server.
Update moved resources. If a file was relocated, update the href or src attribute to point to the new location.
Replace unavailable external resources. If a third-party resource is no longer available, find an alternative source, host a copy yourself, or remove the reference.

Examples

Broken image reference (triggers the error)

<imgsrc="https://example.com/images/photo.jpeg"alt="A scenic landscape">

If photo.jpeg doesn't exist at that path (perhaps the actual file is named photo.jpg), the validator will report a 404 error.

Fixed image reference

<imgsrc="https://example.com/images/photo.jpg"alt="A scenic landscape">

Broken stylesheet reference (triggers the error)

<linkrel="stylesheet"href="/css/Styles.css">

If the file on the server is actually named styles.css (lowercase), a case-sensitive server will return a 404.

Fixed stylesheet reference

<linkrel="stylesheet"href="/css/styles.css">

Broken script reference with incorrect path (triggers the error)

<scriptsrc="/assets/js/old-directory/app.js"></script>

If the script was moved to a different directory, this path no longer resolves.

Fixed script reference

<scriptsrc="/assets/js/app.js"></script>

Using a relative path incorrectly (triggers the error)

If your HTML file is at /pages/about.html and you reference an image like this:

<imgsrc="images/logo.png"alt="Company logo">

The browser will look for /pages/images/logo.png. If the image actually lives at /images/logo.png, this will fail.

Fixed with a root-relative path

<imgsrc="/images/logo.png"alt="Company logo">

The leading / ensures the path is resolved from the root of the site, regardless of where the HTML document is located.

HTTP resource not retrievable. The HTTP status from the remote server was: 405

HTML language standard

HTTP resource not retrievable. The HTTP status from the remote server was: 429.

HTTP status code 429 is defined in RFC 6585 and signals that a client has sent too many requests in a given time period. When the W3C Validator encounters your HTML, it doesn't just parse the markup — it also attempts to retrieve linked resources like stylesheets, scripts, and images to perform thorough validation. If any of those resources are hosted on a server that enforces rate limits (which is common with CDNs, API providers, and popular hosting platforms), the server may reject the validator's request with a 429 response.

This is not a syntax error in your HTML. Your markup may be perfectly valid. The issue is environmental: the remote server is temporarily refusing connections from the validator. However, because the validator cannot retrieve the resource, it cannot fully verify everything about your page, so it flags the problem.

Common Causes

Rapid repeated validation: Running the validator many times in quick succession against pages that reference the same external resources.
Shared rate limits: The W3C Validator service shares outbound IP addresses, so other users' validation requests may count against the same rate limit on the remote server.
Aggressive server-side rate limiting: The remote server or its CDN (e.g., Cloudflare, AWS CloudFront) has strict rate-limiting rules that block automated HTTP clients quickly.
Many external resources: A page that references numerous resources from the same external host may trigger rate limits in a single validation pass.

How to Fix It

Wait and retry

Since 429 is a temporary condition, simply waiting a few minutes and revalidating is often enough. Some servers include a Retry-After header in the 429 response indicating how long to wait, though the validator may not surface this detail.

Reduce validation frequency

If you're running automated validation (e.g., in a CI/CD pipeline), space out your requests. Avoid validating dozens of pages in rapid-fire succession.

Host resources locally

If you control the website, consider self-hosting critical resources rather than relying on third-party CDNs. This gives you full control over availability and eliminates third-party rate-limit issues during validation.

Adjust server rate limits

If you own the server that's returning 429, review your rate-limiting configuration. You may want to whitelist the W3C Validator's user agent or IP range, or relax limits that are overly aggressive for legitimate automated tools.

Examples

Page that may trigger the issue

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<linkrel="stylesheet"href="https://cdn.example.com/styles/main.css">

<scriptsrc="https://cdn.example.com/scripts/app.js"></script>

</head>

<body>

<h1>Hello, world!</h1>

</body>

</html>

If cdn.example.com rate-limits the validator, both the stylesheet and script fetches could fail with a 429, producing two "HTTP resource not retrievable" messages.

Fix: Self-host the resources

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<linkrel="stylesheet"href="/css/main.css">

<scriptsrc="/js/app.js"></script>

</head>

<body>

<h1>Hello, world!</h1>

</body>

</html>

By serving main.css and app.js from your own domain, you eliminate the dependency on a third-party server's rate limits during validation.

Fix: Reduce external dependencies

If self-hosting isn't feasible, minimize the number of external resources from a single host to lower the chance of hitting rate limits:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<linkrel="stylesheet"href="https://cdn.example.com/bundle.css">

</head>

<body>

<h1>Hello, world!</h1>

<scriptsrc="https://cdn.example.com/bundle.js"></script>

</body>

</html>

Bundling multiple files into single resources reduces the total number of requests the validator needs to make to the external server, making rate-limit errors less likely.

HTTP resource not retrievable. The HTTP status from the remote server was: 500.

HTTP resource not retrievable. The HTTP status from the remote server was: 502.

Understanding the 502 Bad Gateway Error

When you submit a URL to the W3C HTML Validator, the validator makes an HTTP request to fetch your page so it can analyze the markup. A 502 Bad Gateway status code means that some server acting as a gateway or proxy between the validator and your origin server received an invalid or incomplete response. Because the validator never receives your HTML content, it cannot perform any validation and reports this retrieval error instead.

This is fundamentally different from an HTML issue. Your markup could be perfectly valid, but the validator simply cannot see it. The problem lies somewhere in the chain of servers that handle the request.

Common Causes

A 502 error can be triggered by several infrastructure-level issues:

Origin server is down or crashing. If your web application (e.g., Node.js, PHP-FPM, Django) has crashed or is unresponsive, the reverse proxy (e.g., Nginx, Apache) sitting in front of it will return a 502.
Server overload or timeout. If your application takes too long to generate a response, the gateway may time out and return a 502 before the response is ready.
CDN or proxy misconfiguration. Services like Cloudflare, AWS CloudFront, or Varnish may return 502 if they cannot reach your origin server, or if SSL/TLS settings between the CDN and origin are mismatched.
Firewall or IP blocking. Your server's firewall or hosting provider may be blocking requests from the validator's IP address, causing the gateway to fail.
DNS propagation issues. If you recently changed DNS records, some servers in the chain may be resolving to an outdated or invalid address.
Temporary networking issues. Transient network problems between servers can cause intermittent 502 errors.

How to Fix It

Since this is not an HTML problem, you won't be editing any markup. Instead, follow these steps:

Verify your site is accessible. Open the URL you're trying to validate in your own browser. If you also see a 502 error, the problem is on your server and needs to be fixed there first.
Check your server logs. Look at the error logs for your reverse proxy (Nginx, Apache) and your application server. They will usually indicate why the upstream connection failed.
Inspect your CDN or proxy settings. If you use a CDN like Cloudflare, check its dashboard for error reports. Ensure the SSL mode matches your origin server's configuration (e.g., "Full (Strict)" requires a valid certificate on your origin).
Confirm no IP-based blocking. The W3C Validator makes requests from its own servers. Make sure your firewall, .htaccess rules, or hosting provider aren't blocking external automated requests.
Check for authentication barriers. If your site requires HTTP authentication, a login, or is behind a VPN, the validator cannot access it. You'll need to use the validator's "Validate by Direct Input" option instead, pasting your HTML directly.
Wait and retry. If the issue is a temporary server overload or network blip, simply waiting a few minutes and trying again may resolve it.
Contact your hosting provider. If the error persists and you can't identify the cause, your hosting support team can investigate the server-side issue.

Alternatives When Your Server Is Unavailable

If you cannot resolve the server issue immediately but still need to validate your HTML, you have two options that bypass the URL fetch entirely:

Validate by Direct Input

Go to the W3C Validator, select the "Validate by Direct Input" tab, and paste your HTML source code directly.

Validate by File Upload

Select the "Validate by File Upload" tab and upload your .html file from your local machine.

Examples

Even though this error is not caused by HTML, here's an illustration of valid markup you might be trying to validate when encountering this issue:

A valid HTML page that the validator cannot reach

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<h1>Welcome</h1>

<p>This page is perfectly valid, but the validator cannot fetch it due to a 502 error.</p>

</body>

</html>

If submitting the URL https://example.com/my-page produces the "HTTP resource not retrievable (502)" message, paste the above source code into the "Validate by Direct Input" field instead. The validator will then be able to check your markup without needing to fetch it from the server.

HTTP resource not retrievable. The HTTP status from the remote server was: 503.

html
503

When the W3C Validator encounters a URL in your HTML — whether in a <link>, <script>, <img>, or any other element that references an external resource — it may attempt to retrieve that resource as part of the validation process. If the remote server returns an HTTP 503 status code, the validator cannot fetch the resource and raises this error. The 503 status code specifically means "Service Unavailable," indicating a temporary condition on the server side.

This error is not a problem with your HTML syntax. It's an infrastructure issue that can be caused by several factors:

Server maintenance: The remote server is temporarily down for updates or scheduled maintenance.
Server overload: The server is handling too many requests and cannot respond in time.
Rate limiting: Some servers detect automated requests (like those from the validator) and respond with 503 to throttle traffic.
CDN or hosting issues: The content delivery network or hosting provider is experiencing temporary problems.
Incorrect URL: The resource URL may point to a server that no longer hosts the expected content.

While this isn't a standards compliance issue per se, it's important to address because unreachable resources can affect your page's rendering, functionality, and accessibility. A missing stylesheet means unstyled content, a missing script means broken interactivity, and a missing image means absent visual information.

How to Fix It

Verify the URL: Open the referenced URL directly in a browser to confirm it's valid and accessible.
Retry later: Since 503 is a temporary status, simply re-running the validator after some time often resolves the issue.
Host resources locally: For critical assets like stylesheets and scripts, consider self-hosting them rather than relying on third-party servers.
Use reliable CDNs: If you use a CDN, choose one with high uptime guarantees (e.g., established providers for popular libraries).
Add fallbacks: For scripts loaded from external CDNs, consider including a local fallback.

Examples

External resource that may trigger a 503

<linkrel="stylesheet"href="https://example.com/styles/main.css">

<scriptsrc="https://example.com/libs/library.js"></script>

If example.com is temporarily unavailable, the validator will report the 503 error for each of these resources.

Fix: Host resources locally

<linkrel="stylesheet"href="/css/main.css">

<scriptsrc="/js/library.js"></script>

By hosting the files on your own server, you eliminate the dependency on a third-party server's availability and ensure the validator (and your users) can always access them.

Fix: Use a reliable CDN with a local fallback

<scriptsrc="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"></script>

if(typeofjQuery==="undefined"){

vars=document.createElement("script");

s.src="/js/jquery.min.js";

document.head.appendChild(s);

}

</script>

This approach loads jQuery from a well-known CDN but falls back to a local copy if the CDN is unavailable. While this fallback pattern doesn't prevent the validator warning itself, it ensures your page works for real users even when the CDN is down.

Fix: Validate using "text input" mode

If the 503 errors persist and are caused by the validator's requests being blocked or rate-limited, you can work around the issue by validating your HTML using the validator's "Validate by Direct Input" option. Paste your HTML source code directly into the validator at https://validator.w3.org/#validate_by_input. This still validates your markup structure and syntax, though the validator may not check externally referenced resources.

Keep in mind that a 503 error during validation is almost always temporary. If you've confirmed your URLs are correct and the resources load fine in a browser, the safest approach is simply to wait and validate again later.

HTTP resource not retrievable. The HTTP status from the remote server was: 504.

When you submit a URL to the W3C HTML Validator, the validator acts as an HTTP client: it sends a request to your server, downloads the HTML response, and then checks it for errors. A 504 Gateway Timeout status means the validator's request never received a timely response. The connection either timed out at your server, at an intermediary proxy or CDN, or somewhere along the network path.

This is fundamentally different from an HTML validation error. Your markup isn't being evaluated at all — the validator simply cannot reach it. Until the retrieval succeeds, no validation can take place.

Common Causes

Several things can prevent the validator from fetching your page:

Slow server response — If your page takes a long time to generate (heavy database queries, unoptimized server-side code, resource-intensive CMS), the validator may time out before receiving a response.
Firewall or WAF rules — A Web Application Firewall or security plugin may be blocking requests from the validator's IP addresses or user agent because they don't look like typical browser traffic.
Geographic or IP-based restrictions — If your server restricts access by region or IP range, the validator (hosted in a different location) may be blocked.
Private or local network — Sites running on localhost, an intranet, or behind a VPN are not reachable from the public internet.
Reverse proxy or CDN misconfiguration — An intermediary like Nginx, Cloudflare, or a load balancer may be timing out while waiting for your origin server.
Server is down or overloaded — The server may simply be unresponsive at the time of the request.

How to Fix It

1. Verify your site is publicly accessible

Open your URL in a browser from a different network (for example, using your phone's mobile data instead of your office Wi-Fi). If you can't reach it externally, the validator can't either.

2. Check server response time

Your page should respond within a few seconds. Use tools like curl to test response time from the command line:

curl-o/dev/null-s-w"HTTP Status: %{http_code}\nTime: %{time_total}s\n"https://example.com/your-page

If the response takes more than 10–15 seconds, consider optimizing your server-side code, enabling caching, or upgrading your hosting.

3. Check firewall and security rules

Review your server's firewall settings, .htaccess rules, or security plugin configuration. Ensure you're not blocking requests based on user agent strings or IP ranges that would affect the validator. The W3C Validator identifies itself with a specific User-Agent header — make sure it's not being rejected.

4. Use direct input as a workaround

If you cannot make your site publicly accessible (e.g., it's a staging environment), you can validate your HTML by pasting it directly into the validator instead of submitting a URL.

Go to https://validator.w3.org/#validate_by_input and paste your HTML source into the text area. This bypasses the network retrieval entirely.

Examples

Validating a page on a private network (will fail with 504)

Submitting a URL like the following to the W3C Validator will fail because the validator cannot reach private or local addresses:

http://192.168.1.50/index.html

http://localhost:3000/about.html

http://my-staging-site.internal/page.html

Using direct input instead (works)

Copy your HTML source and paste it into the validator's "Validate by Direct Input" tab:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<h1>Welcome</h1>

<p>This content can be validated by pasting it directly.</p>

</body>

</html>

This approach lets you validate your markup regardless of server accessibility.

When to Contact Your Hosting Provider

If your site is intended to be publicly accessible but the validator consistently receives a 504 error, the issue likely lies with your server infrastructure. Contact your web hosting provider or server administrator and ask them to investigate:

Whether a reverse proxy (Nginx, Apache, or a CDN) is timing out
Whether any rate limiting or bot protection is blocking automated requests
Whether the origin server is responding slowly under load

Once your server responds reliably to external HTTP requests, the W3C Validator will be able to fetch and validate your HTML normally.

HTTP resource not retrievable. The HTTP status from the remote server was: 508.

“<” in attribute name. Probable cause: “>” missing immediately before.

Internal encoding declaration “utf-8” disagrees with the actual encoding of the document (“windows-1252”).

When a browser or validator reads your HTML document, it looks at the <meta charset="..."> declaration to determine how to decode the bytes in the file. Every character encoding maps bytes to characters differently. UTF-8 and Windows-1252 share the same mappings for basic ASCII characters (letters A–Z, digits, common punctuation), but they diverge for bytes in the 0x80–0x9F range. Windows-1252 uses these bytes for characters like €, ", ", —, and ™, while UTF-8 treats them as invalid or interprets them as parts of multi-byte sequences. When the declared encoding doesn't match the actual encoding, the validator raises this error, and browsers may render characters incorrectly.

This is a problem for several reasons:

Broken text display: Characters like curly quotes (" "), em dashes (—), and accented letters (é, ñ) can appear as mojibake — sequences like â€" or Ã© — confusing your readers.
Standards compliance: The HTML specification requires that the declared encoding match the actual byte encoding of the file. A mismatch is a conformance error.
Accessibility: Screen readers and other assistive technologies rely on correct character interpretation. Garbled text is unintelligible to these tools.
Search engines: Encoding mismatches can cause search engines to index corrupted text, hurting your content's discoverability.

How to fix it

The best approach is to re-save your file in UTF-8 encoding. Most modern text editors and IDEs support this:

VS Code: Click the encoding indicator in the bottom status bar (it may say "Windows 1252"), select "Save with Encoding," and choose "UTF-8."
Sublime Text: Go to File → Save with Encoding → UTF-8.
Notepad++: Go to Encoding → Convert to UTF-8, then save the file.
Vim: Run :set fileencoding=utf-8 then :w.

After re-saving, make sure your <meta charset="utf-8"> declaration remains in the <head>. The <meta charset> tag should appear as early as possible — ideally as the first element inside <head> — because the browser needs to know the encoding before parsing any other content.

If your workflow or legacy system absolutely requires Windows-1252 encoding, you can change the declaration to <meta charset="windows-1252"> instead. However, this is strongly discouraged. UTF-8 is the universal standard for the web, supports virtually all characters from all languages, and is recommended by the WHATWG HTML specification.

Examples

Incorrect — encoding mismatch triggers the error

The file is saved in Windows-1252, but the meta tag declares UTF-8:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<p>She said, "Hello!"</p>

</body>

</html>

This produces the validator error: Internal encoding declaration "utf-8" disagrees with the actual encoding of the document ("windows-1252").

Correct — file saved as UTF-8 with matching declaration

Re-save the file in UTF-8 encoding. The meta tag and the file's byte encoding now agree:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<p>She said, "Hello!"</p>

</body>

</html>

Alternative — declaration changed to match Windows-1252 file

If you cannot change the file encoding, update the charset declaration to match. This eliminates the mismatch error but is not the recommended approach:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="windows-1252">

</head>

<body>

<p>She said, "Hello!"</p>

</body>

</html>

Tips for preventing this issue

Configure your editor to default to UTF-8 for all new files.
If you copy text from Microsoft Word or other desktop applications, be aware that they often use Windows-1252 curly quotes and special characters. Pasting this text into a UTF-8 file is fine as long as your editor properly converts the characters to UTF-8 bytes when saving.
Use <meta charset="utf-8"> as the very first element inside <head> so the encoding is established before the browser encounters any other content.
If your server sends an HTTP Content-Type header with a charset parameter, make sure it also matches — for example, Content-Type: text/html; charset=utf-8.

Internal encoding declaration “windows-1251” disagrees with the actual encoding of the document (“utf-8”).

When a browser loads an HTML document, it needs to know which character encoding to use to correctly interpret the bytes in the file. The <meta> tag's charset attribute (or the http-equiv="Content-Type" declaration) tells the browser what encoding to expect. If this declaration says windows-1251 but the file is actually saved as utf-8, the browser faces conflicting signals — the declared encoding disagrees with the actual byte content.

This mismatch matters for several reasons:

Broken text rendering: Characters outside the basic ASCII range (such as accented letters, Cyrillic, CJK characters, emoji, and special symbols) may display as garbled or replacement characters (often seen as Ð sequences, �, or other mojibake).
Data integrity: Form submissions and JavaScript string operations may produce corrupted data if the browser interprets the encoding incorrectly.
Standards compliance: The WHATWG HTML Living Standard requires that the encoding declaration match the actual encoding of the document. Validators flag this mismatch as an error.
Inconsistent behavior: Different browsers may handle the conflict differently — some may trust the <meta> tag, others may sniff the actual encoding — leading to unpredictable results across user agents.

How to fix it

Determine the actual encoding of your file. Most modern text editors (VS Code, Sublime Text, Notepad++) display the file encoding in the status bar. If your file is saved as UTF-8 (which is the recommended encoding for all new web content), your <meta> tag must reflect that.
Update the <meta> tag to declare utf-8 instead of windows-1251.
Prefer the shorter charset syntax introduced in HTML5, which is simpler and equivalent to the older http-equiv form.
Place the encoding declaration within the first 1024 bytes of the document, ideally as the first element inside <head>, so the browser encounters it before parsing other content.

Examples

❌ Incorrect: declared encoding doesn't match actual file encoding

The file is saved as UTF-8 but the <meta> tag declares windows-1251:

<head>

<metacharset="windows-1251">

</head>

Or using the older http-equiv syntax:

<head>

<metahttp-equiv="Content-Type"content="text/html; charset=windows-1251">

</head>

✅ Correct: declared encoding matches the actual UTF-8 file

Using the modern HTML5 charset attribute:

<head>

<metacharset="utf-8">

</head>

Or using the equivalent http-equiv form:

<head>

<metahttp-equiv="Content-Type"content="text/html; charset=utf-8">

</head>

✅ Correct: full document example

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

What if you actually need `windows-1251`?

If your content genuinely requires windows-1251 encoding (for example, a legacy Cyrillic text file), you need to re-save the file in windows-1251 encoding using your text editor. However, UTF-8 is strongly recommended for all web content because it supports every Unicode character and is the default encoding for HTML5. Converting your file to UTF-8 and updating the <meta> tag accordingly is almost always the better path forward.

“label” element with multiple labelable descendants.

The HTML specification defines a <label> as a caption for a specific form control. When you use the implicit labeling technique — wrapping a form control inside a <label> — the browser automatically associates the label text with that single control. If multiple labelable elements appear inside the same <label>, the association becomes ambiguous. Browsers may pick the first one, the last one, or behave inconsistently across implementations.

Labelable elements include <input> (except type="hidden"), <select>, <textarea>, <button>, <meter>, <output>, and <progress>. Any combination of two or more of these inside a single <label> triggers this validation error.

This matters for accessibility. Screen readers rely on the label-to-control association to announce what a form field is for. When the association is ambiguous, assistive technology may announce the wrong label for a control, or skip one entirely, leaving users confused about what information to enter.

To fix this issue, split the <label> so that each one wraps exactly one form control, or use the for attribute to explicitly associate each label with a control by its id.

Examples

❌ Incorrect: multiple labelable elements inside one label

<label>

Name

<inputtype="text"name="name">

Age

<inputtype="number"name="age">

</label>

The single <label> contains two <input> elements, so the browser cannot determine which control the label text refers to.

✅ Correct: separate labels for each control

<label>

Name

<inputtype="text"name="name">

</label>

<label>

Age

<inputtype="number"name="age">

</label>

❌ Incorrect: mixing different labelable elements inside one label

<label>

Preferences

<selectname="color">

</select>

<textareaname="notes"></textarea>

</label>

✅ Correct: using explicit `for` attributes

<labelfor="color">Favorite color</label>

<selectid="color"name="color">

</select>

<labelfor="notes">Notes</label>

<textareaid="notes"name="notes"></textarea>

✅ Correct: single labelable descendant with implicit association

This is the pattern that works perfectly — one <label> wrapping exactly one control:

<label>

Age

<selectname="age">

<option>Young</option>

</select>

</label>

❌ Incorrect: hidden inputs don't count, but other inputs do

Note that <input type="hidden"> is not a labelable element, so it won't trigger this error on its own. However, combining a visible input with another labelable control still causes the issue:

<label>

Subscribe

<inputtype="checkbox"name="subscribe">

<buttontype="button">More info</button>

</label>

✅ Correct: separate each control into its own label

<label>

Subscribe

<inputtype="checkbox"name="subscribe">

</label>

<buttontype="button">More info</button>

In this case, the <button> doesn't need a <label> at all — its text content serves as its accessible name. Only form controls that need a visible caption should be wrapped in a <label>.

Legacy doctype. Expected “<!DOCTYPE html>”.

legacy doctype

Legacy encoding “iso-8859-15” used. Documents must use UTF-8.

Legacy encoding “windows-1252” used. Documents must use UTF-8.

The HTML living standard mandates UTF-8 as the only permitted character encoding for HTML documents. Legacy encodings like windows-1252, iso-8859-1, shift_jis, and others were common in older web pages, but they support only a limited subset of characters. UTF-8, on the other hand, can represent every character in the Unicode standard, making it universally compatible across languages and scripts.

This issue typically arises from one or more of these causes:

Missing or incorrect <meta charset> declaration — Your document either lacks a charset declaration or explicitly declares a legacy encoding like <meta charset="windows-1252">.
File not saved as UTF-8 — Even with the correct <meta> tag, if your text editor saves the file in a different encoding, characters may become garbled (mojibake).
Server sends a conflicting Content-Type header — The HTTP Content-Type header can override the in-document charset declaration. If your server sends Content-Type: text/html; charset=windows-1252, the browser will use that encoding regardless of what the <meta> tag says.

Why This Matters

Standards compliance: The WHATWG HTML living standard explicitly states that documents must be encoded in UTF-8. Using a legacy encoding makes your document non-conforming.
Internationalization: Legacy encodings like windows-1252 only support a limited set of Western European characters. If your content ever includes characters outside that range—emoji, CJK characters, Cyrillic, Arabic, or even certain punctuation—they won't render correctly.
Security: Mixed or ambiguous encodings can lead to security vulnerabilities, including certain types of cross-site scripting (XSS) attacks that exploit encoding mismatches.
Consistency: When the declared encoding doesn't match the actual file encoding, browsers may misinterpret characters, leading to garbled text that's difficult to debug.

How to Fix It

Step 1: Declare UTF-8 in your HTML

Add a <meta charset="utf-8"> tag as the first element inside <head>. It must appear within the first 1024 bytes of the document so browsers can detect it early.

Step 2: Save the file as UTF-8

In most modern text editors and IDEs, you can set the file encoding:

VS Code: Click the encoding label in the bottom status bar and select "Save with Encoding" → "UTF-8".
Sublime Text: Go to File → Save with Encoding → UTF-8.
Notepad++: Go to Encoding → Convert to UTF-8.

If your file already contains characters encoded in windows-1252, simply changing the declaration without re-encoding the file will cause those characters to display incorrectly. You need to convert the file's actual encoding.

Step 3: Check your server configuration

If your server sends a charset parameter in the Content-Type HTTP header, make sure it specifies UTF-8. For example, in Apache you can add this to your .htaccess file:

AddDefaultCharset UTF-8

In Nginx, you can set it in your server block:

charset utf-8;

Examples

Incorrect: Legacy encoding declared

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="windows-1252">

</head>

<body>

<p>Hello world</p>

</body>

</html>

This triggers the error because windows-1252 is a legacy encoding.

Incorrect: Using the long-form `http-equiv` with a legacy encoding

<metahttp-equiv="Content-Type"content="text/html; charset=iso-8859-1">

This older syntax also triggers the error when it specifies a non-UTF-8 encoding.

Correct: UTF-8 declared properly

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<p>Hello world</p>

</body>

</html>

The <meta charset="utf-8"> tag appears as the first child of <head>, and the file itself should be saved with UTF-8 encoding.

Correct: Using `http-equiv` with UTF-8

<metahttp-equiv="Content-Type"content="text/html; charset=utf-8">

While the shorter <meta charset="utf-8"> form is preferred, this longer syntax is also valid as long as it specifies UTF-8.

Malformed byte sequence:

When a browser or validator reads your HTML file, it interprets the raw bytes according to a character encoding — most commonly UTF-8. Each encoding has rules about which byte sequences are valid. For example, in UTF-8, bytes above 0x7F must follow specific multi-byte patterns. If the validator encounters a byte or sequence of bytes that violates these rules, it reports a "malformed byte sequence" error because it literally cannot decode the bytes into meaningful characters.

This problem commonly arises in a few scenarios:

Encoding mismatch: Your file is saved as Windows-1252 (or Latin-1, ISO-8859-1) but the document declares UTF-8, or vice versa. Characters like curly quotes (" "), em dashes (—), or accented letters (é, ñ) are encoded differently across these encodings, producing invalid byte sequences when interpreted under the wrong one.
Copy-pasting from word processors: Content copied from Microsoft Word or similar applications often includes "smart quotes" and special characters encoded in Windows-1252, which can produce malformed bytes in a UTF-8 file.
File corruption: The file was partially corrupted during transfer (e.g., FTP in the wrong mode) or by a tool that modified it without respecting its encoding.
Mixed encodings: Parts of the file were written or appended using different encodings, resulting in some sections containing invalid byte sequences.

This is a serious problem because browsers may display garbled text (mojibake), skip characters entirely, or substitute replacement characters (�). It also breaks accessibility tools like screen readers, which may mispronounce or skip corrupted text. Search engines may index garbled content, harming your SEO.

How to Fix It

Declare UTF-8 encoding in your HTML with <meta charset="utf-8"> as the first element inside <head>.
Save your file as UTF-8 in your text editor. Most editors have an option like "Save with Encoding" or "File Encoding" in the status bar or save dialog. Choose "UTF-8" or "UTF-8 without BOM."
Re-encode the file if it was originally saved in a different encoding. Tools like iconv on the command line can convert between encodings:
iconv -f WINDOWS-1252 -t UTF-8 input.html -o output.html
Replace problematic characters by re-typing them or using HTML character references if needed.
Check your server configuration. If your server sends a Content-Type header with a charset that conflicts with the file's actual encoding (e.g., Content-Type: text/html; charset=iso-8859-1 for a UTF-8 file), the validator will use the HTTP header's encoding, causing mismatches.

Examples

Incorrect — Encoding mismatch

A file saved in Windows-1252 but declaring UTF-8. The byte 0xE9 represents é in Windows-1252 but is an invalid lone byte in UTF-8, triggering the malformed byte sequence error.

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<p>Resumé</p>

</body>

</html>

Correct — File properly saved as UTF-8

The same document, but the file is actually saved in UTF-8 encoding. The character é is stored as the two-byte sequence 0xC3 0xA9, which is valid UTF-8.

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

<p>Resumé</p>

</body>

</html>

Alternative — Using character references

If you can't resolve the encoding issue immediately, you can use HTML character references to avoid non-ASCII bytes entirely:

<p>Resumé</p>

Or using the named reference:

<p>Resumé</p>

Both render as "Resumé" regardless of file encoding, though this is a workaround — properly saving the file as UTF-8 is the preferred long-term solution.

How to fix it

Examples

❌ Missing closing tag for a nested element

✅ Fixed: close the inner element first

❌ Misordered closing tags

✅ Fixed: close tags in reverse order

❌ Multiple levels of broken nesting

✅ Fixed: close the anchor before the paragraph

❌ Typo in a closing tag causing a mismatch

✅ Fixed: use the correct closing tag

How forbidden characters get into your code

How to fix it

Examples

Incorrect — contains a forbidden control character

Correct — forbidden character removed

Incorrect — NULL character in an attribute value

Correct — NULL character removed from attribute

Allowed control characters

Examples

Space inside the end tag

Trying to close a void element

Unescaped markup in text content

Accidental or malformed sequences

Full document example

Examples

❌ Heading nested inside another heading

✅ Headings as siblings

❌ Missing closing slash causes nesting

✅ Properly closed heading tags

❌ Using nested headings for visual hierarchy inside a heading

✅ Using a span for supplementary text within a heading

✅ Using the hgroup element

How to fix it

Examples

Incorrect: <img> inside <svg>

Correct: using SVG <image> element

Correct: with an accessible name via <title>

Incorrect: <img> inside <math>

Correct: <img> inside <mtext> within <math>

Correct: <img> moved outside <math>

Incorrect: mixed HTML content inside <svg>

Correct: using <image> alongside other SVG elements

Invalid example

Valid example using foreignObject

Valid example in MathML

How to fix it

Common Causes

How to Fix

Examples

Incorrect server behavior (returns 202)

Correct server behavior (returns 200)

Verifying the status code with curl

Common Causes

Why This Matters

How to Fix It

Examples

Resource blocked by remote server

Fixed: Host the resource locally

Fixed: Use a publicly accessible CDN

Script blocked by hotlink protection

Fixed: Use a reliable public source

Image blocked by access restrictions

Fixed: Host the image yourself

How to Fix It

Examples

Broken image reference (triggers the error)

Fixed image reference

Broken stylesheet reference (triggers the error)

Fixed stylesheet reference

Broken script reference with incorrect path (triggers the error)

Fixed script reference

Using a relative path incorrectly (triggers the error)

Fixed with a root-relative path

HTML Example

Fix: Host the Resource Locally

Common Causes

How to Fix It

Wait and retry

Reduce validation frequency

✅ Using a `span` for supplementary text within a heading

✅ Using the `hgroup` element

Incorrect: `<img>` inside `<svg>`

Correct: using SVG `<image>` element

Correct: with an accessible name via `<title>`

Incorrect: `<img>` inside `<math>`

Correct: `<img>` inside `<mtext>` within `<math>`

Correct: `<img>` moved outside `<math>`

Incorrect: mixed HTML content inside `<svg>`

Correct: using `<image>` alongside other SVG elements

Valid example using `foreignObject`

What if you actually need `windows-1251`?

✅ Correct: using explicit `for` attributes