HTML Guides

Attribute with the local name “xmlns:o” is not serializable as XML 1.0.

The W3C HTML Validator raises this error because HTML5 does not support arbitrary XML namespace declarations. In XML, the xmlns: prefix is used to bind namespace prefixes to URIs, allowing elements and attributes from different vocabularies to coexist. However, HTML5 uses its own parsing rules that are distinct from XML, and the only namespace attribute recognized in HTML5 is the plain xmlns attribute on the <html> element (set to http://www.w3.org/1999/xhtml). Colonized namespace attributes like xmlns:o, xmlns:v, xmlns:w, and others are not part of the HTML5 specification.

The xmlns:o="urn:schemas-microsoft-com:office:office" namespace specifically comes from Microsoft Office. When you save a Word document as HTML or copy-paste content from Office applications into an HTML editor, Office injects its own namespace declarations and proprietary markup. This markup is intended for round-tripping the document back into Office and serves no purpose on the web.

Beyond validation, leaving these attributes in place can cause practical problems. The HTML5 parser in browsers silently ignores or misinterprets these namespace declarations, meaning they add dead weight to your markup. They also increase file size unnecessarily and can confuse other tools that process your HTML, such as screen readers, search engine crawlers, or content management systems.

How to Fix

Remove the xmlns:o attribute from any element where it appears (typically the <html> tag).
Remove related Office namespace attributes such as xmlns:v, xmlns:w, xmlns:x, and xmlns:st1, as these will trigger similar errors.
Remove any elements or attributes using those namespace prefixes, such as <o:p>, <v:shape>, or <w:wrap>, since they are not valid HTML5 elements and browsers do not render them meaningfully.
Clean up Office-generated HTML thoroughly if you're converting Word documents to web content. Consider using a dedicated HTML cleaning tool or a paste-as-plain-text option in your editor.

Examples

Incorrect: Office namespace attributes on the `<html>` element

This markup contains multiple Microsoft Office namespace declarations that trigger validation errors:

<!DOCTYPE html>

<htmlxmlns:o="urn:schemas-microsoft-com:office:office"

xmlns:w="urn:schemas-microsoft-com:office:word"

xmlns:v="urn:schemas-microsoft-com:vml">

<head>

<title>My Document</title>

</head>

<body>

<h1>Meeting Notes</h1>

<p>Welcome to the meeting.<o:p></o:p></p>

</body>

</html>

Correct: Clean HTML5 without Office namespaces

Remove all xmlns: prefixed attributes and any Office-specific elements like <o:p>:

<!DOCTYPE html>

<htmllang="en">

<head>

<title>My Document</title>

</head>

<body>

<h1>Meeting Notes</h1>

<p>Welcome to the meeting.</p>

</body>

</html>

Incorrect: Office namespace on a non-root element

Sometimes Office markup appears deeper in the document:

<divxmlns:o="urn:schemas-microsoft-com:office:office">

<p>Some content<o:p></o:p></p>

</div>

Correct: Cleaned-up version

<div>

<p>Some content</p>

</div>

By stripping out all Microsoft Office namespace declarations and their associated proprietary elements, your HTML becomes standards-compliant, lighter, and more compatible across browsers and assistive technologies. If you frequently convert Office documents to HTML, consider using a cleanup tool like DirtyMarkup or the "Paste as plain text" feature in your content editor to avoid these issues from the start.

Bad value “” for attribute “poster” on element “video”: Must be non-empty.

poster
video

CSS: “grid-template-columns”: X is not a “grid-template-columns” value.

The grid-template-columns property defines the column track sizes of a CSS grid container. When the W3C validator reports that a particular value "is not a grid-template-columns value," it means the parser encountered something it cannot interpret as a valid track size or track listing.

This error can be triggered by many common mistakes: a simple typo (like auто instead of auto), using a CSS custom property (the validator may not resolve var() references), forgetting units on a length value (e.g., 100 instead of 100px), using JavaScript-like terms (e.g., undefined or null), or using newer syntax that the validator's CSS parser doesn't yet support.

While browsers are generally forgiving and will simply ignore an invalid grid-template-columns declaration, this means your grid layout silently breaks — the container won't form a grid as intended, and content may stack in a single column. Fixing validation errors ensures your layout works predictably across browsers and makes your stylesheets easier to maintain.

Valid values

The grid-template-columns property accepts these value types:

none — the default; no explicit grid columns are defined.
Length and percentage values — px, em, rem, %, vh, vw, etc. (e.g., 200px, 50%).
The fr unit — distributes remaining space proportionally (e.g., 1fr 2fr).
Keywords — auto, min-content, max-content.
The repeat() function — shorthand for repeated track patterns (e.g., repeat(3, 1fr)).
The minmax() function — sets a minimum and maximum size for a track (e.g., minmax(150px, 1fr)).
The fit-content() function — clamps the track to a given maximum (e.g., fit-content(300px)).
Named grid lines — defined with square brackets (e.g., [sidebar-start] 200px [sidebar-end content-start] 1fr [content-end]).
Any combination of the above.

Common causes

Typos or made-up keywords — values like undefined, inherit-grid, or misspelled units.
Missing units — writing 100 instead of 100px. The fr unit, px, and all other units are mandatory (only 0 can be unitless).
Invalid function syntax — missing commas or parentheses in repeat() or minmax().
CSS custom properties — var(--cols) may trigger validator warnings because the validator cannot resolve the variable at parse time. This is typically a false positive.

Examples

Incorrect: invalid keyword

<style>

.grid{

display: grid;

grid-template-columns: undefined;

}

</style>

Incorrect: missing unit on a length

<style>

.grid{

display: grid;

grid-template-columns:2001fr;

}

</style>

Incorrect: malformed `repeat()` syntax

<style>

.grid{

display: grid;

grid-template-columns:repeat(31fr);

}

</style>

Correct: using `fr` units

<style>

.grid{

display: grid;

grid-template-columns:1fr2fr;

}

</style>

Correct: mixing lengths, `fr`, and `auto`

<style>

.grid{

display: grid;

grid-template-columns:250px1fr auto;

}

</style>

Correct: using `repeat()` and `minmax()`

<style>

.grid{

display: grid;

grid-template-columns:repeat(auto-fill,minmax(200px,1fr));

}

</style>

Correct: named grid lines with track sizes

<style>

.grid{

display: grid;

grid-template-columns:[sidebar]240px[content]1fr[aside]200px;

}

</style>

If the validator flags a var() custom property usage and you're confident the variable resolves to a valid value at runtime, the warning can generally be disregarded — this is a known limitation of static CSS validation. For all other cases, double-check spellings, ensure every numeric value (other than 0) has a unit, and verify that function syntax includes the correct commas and parentheses.

Bad value “” for attribute “action” on element “form”: Must be non-empty.

form
action

The action attribute tells the browser where to send form data when the form is submitted. According to the WHATWG HTML living standard, if the action attribute is specified, its value must be a valid non-empty URL potentially surrounded by spaces. An empty string ("") does not satisfy this requirement, which is why the W3C validator flags it.

While some developers use action="" intending the form to submit to the current page's URL, this approach is non-conforming HTML. Browsers do typically interpret an empty action as "submit to the current URL," but relying on this behavior is unnecessary since simply omitting the action attribute achieves the same result in a standards-compliant way. When no action attribute is present, the form submits to the URL of the page containing the form — this is the defined default behavior per the HTML specification.

This issue matters for several reasons:

Standards compliance: Non-conforming HTML can lead to unexpected behavior across different browsers or future browser versions.
Maintainability: Using the correct approach makes your intent clearer to other developers. Omitting action explicitly signals "submit to the current page," while action="" looks like a mistake or a placeholder that was never filled in.
Tooling: Build tools, linters, and automated testing pipelines that rely on valid HTML may flag or break on this error.

How to Fix

You have two options:

Remove the action attribute if you want the form to submit to the current page URL.
Provide a valid URL if the form should submit to a specific endpoint.

Examples

❌ Invalid: Empty `action` attribute

<formaction=""method="post">

<labelfor="email">Email:</label>

<inputtype="email"id="email"name="email">

<buttontype="submit">Subscribe</button>

</form>

This triggers the error: Bad value "" for attribute "action" on element "form": Must be non-empty.

✅ Fixed: Remove the `action` attribute

If you want the form to submit to the current page, simply omit action:

<formmethod="post">

<labelfor="email">Email:</label>

<inputtype="email"id="email"name="email">

<buttontype="submit">Subscribe</button>

</form>

✅ Fixed: Provide a valid URL

If the form should submit to a specific endpoint, supply the URL:

<formaction="/subscribe"method="post">

<labelfor="email">Email:</label>

<inputtype="email"id="email"name="email">

<buttontype="submit">Subscribe</button>

</form>

✅ Fixed: Use a hash as a placeholder for JavaScript-handled forms

If your form is entirely handled by JavaScript and should not navigate anywhere, you can use a # as the action or, preferably, omit action and prevent submission in your script:

<formmethod="post"id="js-form">

<labelfor="query">Search:</label>

<inputtype="text"id="query"name="query">

<buttontype="submit">Search</button>

</form>

document.getElementById('js-form').addEventListener('submit',function(e){

e.preventDefault();

// Handle form data with JavaScript

});

In this case, omitting action is the cleanest solution. The JavaScript preventDefault() call stops the browser from actually submitting the form, so the action value is never used.

Bad value “” for attribute “src” on element “script”: Must be non-empty.

Attribute with the local name “xmlns:v” is not serializable as XML 1.0.

The xmlns:v attribute is a namespace declaration that binds the v prefix to Microsoft's VML namespace (urn:schemas-microsoft-com:vml). VML was a proprietary vector graphics format used primarily by Internet Explorer (versions 5 through 9) for rendering shapes, lines, and other graphical elements. When Microsoft dropped VML support in favor of SVG starting with IE 9, the technology became obsolete.

In HTML5 (the HTML living standard), namespace declarations using the xmlns: prefix pattern are not permitted. The HTML parser does not process these as actual namespace bindings — they are treated as regular attributes with a colon in the name. The validator flags this because such attributes cannot be round-tripped through an XML 1.0 serializer. An attribute name containing a colon implies a namespace prefix in XML, but without a proper namespace declaration in the XML output, the serialization would be invalid. This means your document cannot be reliably converted between HTML and XML formats.

This issue commonly appears in pages generated by older versions of Microsoft Office (Word, Outlook) that export to HTML, or in legacy templates that were designed for IE compatibility. You may also see similar warnings for related attributes like xmlns:o (Office namespace) or xmlns:w (Word namespace).

Why this matters

Standards compliance: HTML5 explicitly does not support custom namespace declarations. Only the built-in namespaces for SVG and MathML are recognized.
No functional benefit: Since no modern browser supports VML, the attribute serves no purpose. It adds dead weight to your markup.
Interoperability: Documents with non-serializable attributes cannot be cleanly processed by XML-based tools, XSLT transformations, or any system that needs valid XML serialization.

How to fix it

Remove the xmlns:v attribute from your <html> element (or wherever it appears).
Remove any other legacy Microsoft namespace declarations such as xmlns:o, xmlns:w, or xmlns:x.
Remove any VML-specific elements (like <v:shape>, <v:oval>, etc.) from your document, as they are not recognized by modern browsers.
Replace VML graphics with SVG if you still need vector graphics functionality. SVG is natively supported in all modern browsers and is part of the HTML standard.

Examples

Incorrect: legacy VML namespace declaration

<!DOCTYPE html>

<htmlxmlns:v="urn:schemas-microsoft-com:vml"xmlns:o="urn:schemas-microsoft-com:office:office"lang="en">

<head>

<title>Legacy VML Page</title>

</head>

<body>

<v:ovalstyle="width:100px;height:75px"fillcolor="blue"></v:oval>

</body>

</html>

This triggers the validator warning for both xmlns:v and xmlns:o, and the <v:oval> element is not recognized by any modern browser.

Correct: namespace removed, VML replaced with SVG

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Modern SVG Page</title>

</head>

<body>

<svgwidth="100"height="75"xmlns="http://www.w3.org/2000/svg">

<ellipsecx="50"cy="37.5"rx="50"ry="37.5"fill="blue"/>

</svg>

</body>

</html>

Correct: simple removal when no vector graphics are needed

If the namespace was included unnecessarily (common with auto-generated HTML), simply remove it:

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Clean Page</title>

</head>

<body>

<p>No legacy namespace attributes needed.</p>

</body>

</html>

If your HTML was exported from Microsoft Office, consider running it through an HTML cleaner or manually stripping all xmlns:* attributes and proprietary elements. The resulting markup will be smaller, valid, and fully compatible with modern browsers.

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

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.

CSS: “color”: X is not a valid color 3 or 6 hexadecimals numbers.

css
color

Hexadecimal color values in CSS must follow a specific format: the # symbol followed by exactly 3 or 6 hexadecimal digits. Each digit can be a number from 0 to 9 or a letter from A to F (case-insensitive). A 3-digit hex code is shorthand where each digit is expanded by duplication — for example, #F00 is equivalent to #FF0000. Common mistakes that trigger this error include using the wrong number of digits (e.g., 1, 2, 4, or 5), including non-hexadecimal characters (like G, Z, or special symbols), or omitting the # prefix.

The color CSS property sets the foreground color of an element's text and text decorations. It also establishes the currentcolor value, which acts as an indirect value for other properties like border-color. Because color cascades to many visual aspects of an element, an invalid value can cause the entire declaration to be ignored, meaning the element may inherit an unexpected color or fall back to browser defaults.

This matters for consistency across browsers. While some browsers may attempt to guess what you meant with a malformed hex code, others will discard the value entirely. This leads to unpredictable rendering. Using valid color values ensures your styles are applied reliably everywhere.

Note that CSS also supports 4-digit and 8-digit hex values (which include an alpha/transparency channel, e.g., #F00A or #FF0000AA). However, the W3C validator's inline style checker may not recognize these newer formats depending on the CSS level being validated. If you need transparency, consider using the rgba() function for broader validation compatibility.

Examples

Invalid hex color values

These examples will trigger the validation error:

<pstyle="color:#F;">Hello</p>

<pstyle="color:#FF;">Hello</p>

<pstyle="color:#FF00;">Hello</p>

<pstyle="color:#FF000;">Hello</p>

<pstyle="color:#FG0000;">Hello</p>

<pstyle="color: FF0000;">Hello</p>

Valid hex color values

Use exactly 3 or 6 hexadecimal digits after the #:

<pstyle="color:#F00;">Hello</p>

<pstyle="color:#FF0000;">Hello</p>

<pstyle="color:#FFF;">Hello</p>

<pstyle="color:#333333;">Hello</p>

<pstyle="color:#3a7bd5;">Hello</p>

Alternative color formats

If hex values are causing issues, CSS offers several other valid ways to specify colors:

<pstyle="color: red;">Hello</p>

<pstyle="color:rgb(255,0,0);">Hello</p>

<pstyle="color:rgba(255,0,0,0.5);">Hello</p>

<pstyle="color:hsl(0,100%,50%);">Hello</p>

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.

A “link” element must not appear as a descendant of a “body” element unless the “link” element has an “itemprop” attribute or has a “rel” attribute whose value contains “dns-prefetch”, “modulepreload”, “pingback”, “preconnect”, “prefetch”, “preload”, “prerender”, or “stylesheet”.

link

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>

<linkrel="canonical"href="https://example.com/page">

<h1>Welcome</h1>

</body>

✅ Move it to `<head>`

<head>

<linkrel="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>

<htmllang="en">

<head>

<imgsrc="photo.jpg"alt="A smiling cat">

<linkrel="canonical"href="https://example.com/">

</head>

<body>

<p>Some content</p>

</body>

</html>

✅ Move the `<img>` to `<body>` where it belongs

<!DOCTYPE html>

<htmllang="en">

<head>

<linkrel="canonical"href="https://example.com/">

</head>

<body>

<imgsrc="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>

<linkrel="stylesheet"href="article-theme.css">

<h2>Article Title</h2>

<p>Content here.</p>

</article>

<linkrel="prefetch"href="/next-page.html">

<linkrel="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>

<divitemscopeitemtype="https://schema.org/Product">

<spanitemprop="name">Widget</span>

<linkitemprop="availability"href="https://schema.org/InStock">

</div>

</body>

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: 405

HTML language standard

The “aria-owns” attribute must point to an element in the same document.

aria-owns

The aria-owns attribute is used to define parent-child relationships in the accessibility tree that aren't reflected in the DOM structure. For example, if a menu visually "owns" items that are placed elsewhere in the markup (perhaps for layout reasons), aria-owns tells assistive technologies that those elements should be treated as children of the owning element. The attribute accepts a space-separated list of one or more IDs.

According to the WAI-ARIA specification, each ID referenced by aria-owns must correspond to an element in the same document. If no matching element is found, the relationship is broken and the accessibility tree becomes inaccurate. This can confuse screen readers and other assistive technologies, potentially making parts of your page inaccessible or misrepresented to users who rely on them.

Common causes of this error:

Typos in the ID value — a small misspelling like aria-owns="drpdown-menu" instead of aria-owns="dropdown-menu".
Referencing an element that doesn't exist — the target element was removed or never added to the page.
Referencing an element in a different document — the target lives inside an <iframe> or a shadow DOM, which are separate document contexts.
Dynamic content timing — the referenced element is added to the DOM by JavaScript after validation or after the aria-owns relationship is evaluated.

How to fix it:

Check that every ID in the aria-owns value exactly matches an id attribute on an element in the same document.
Look for typos or case mismatches — IDs are case-sensitive.
If the target element is inside an <iframe>, restructure your markup so both elements are in the same document, or use a different ARIA approach.
If the element is added dynamically, ensure it exists in the DOM before the aria-owns relationship is needed by assistive technologies.

Examples

Incorrect — referencing a nonexistent ID

The element with id="dropdown-items" does not exist anywhere in the document, so the aria-owns reference is broken.

<buttonaria-owns="dropdown-items">Open Menu</button>

Incorrect — typo in the referenced ID

The button references "menu-lst" but the actual element has id="menu-list".

<buttonaria-owns="menu-lst">Options</button>

<ulid="menu-list">

<li>Option A</li>

<li>Option B</li>

</ul>

Correct — referenced ID exists in the same document

The aria-owns value matches the id of an element present in the same page.

<buttonaria-owns="menu-list">Options</button>

<ulid="menu-list">

<li>Option A</li>

<li>Option B</li>

</ul>

Correct — multiple IDs referenced

When aria-owns lists multiple IDs, each one must have a corresponding element in the document.

<divrole="tree"aria-owns="branch1 branch2 branch3">

File Explorer

</div>

<divrole="treeitem"id="branch1">Documents</div>

<divrole="treeitem"id="branch2">Pictures</div>

<divrole="treeitem"id="branch3">Music</div>

Complete valid example

<!DOCTYPE html>

<htmllang="en">

<head>

<title>aria-owns Example</title>

</head>

<body>

<divrole="combobox"aria-expanded="true"aria-owns="suggestions">

<inputtype="text"aria-autocomplete="list">

</div>

<ulid="suggestions"role="listbox">

<lirole="option">Apple</li>

<lirole="option">Banana</li>

<lirole="option">Cherry</li>

</ul>

</body>

</html>

In this example, the combobox uses aria-owns to claim the suggestions listbox as its child in the accessibility tree, even though the <ul> is a sibling in the DOM. Because the id="suggestions" element exists in the same document, the reference is valid and assistive technologies can correctly associate the two.

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.

The “aria-describedby” attribute must point to an element in the same document.

The aria-describedby attribute is a core part of WAI-ARIA, the Web Accessibility Initiative's specification for making web content more accessible. It works by creating a relationship between an element and one or more other elements that provide additional descriptive text. Screen readers and other assistive technologies use this relationship to announce the descriptive text when a user interacts with the element.

When you set aria-describedby="some-id", the browser looks for an element with id="some-id" in the same document. If no matching element exists, the reference is broken. This means assistive technologies cannot find the description, and the attribute silently does nothing. The W3C validator flags this as an error because a dangling reference indicates a bug — either the referenced element was removed, renamed, or was never added.

This issue commonly arises due to:

Typos in the id value — the aria-describedby value doesn't match the target element's id exactly (the match is case-sensitive).
Dynamic content — the described-by element is rendered conditionally or injected by JavaScript after validation.
Copy-paste errors — markup was copied from another page or component, but the referenced element wasn't included.
Refactoring — an element's id was changed or the element was removed, but the aria-describedby reference wasn't updated.

Multiple id values can be listed in aria-describedby, separated by spaces. Every single id in that list must resolve to an element in the document. If even one is missing, the validator will report an error for that reference.

How to fix it

Check for typos. Compare the value in aria-describedby against the id of the target element. Remember that id matching is case-sensitive — helpText and helptext are different.
Add the missing element. If the descriptive element doesn't exist yet, create it with the matching id.
Remove stale references. If the description is no longer needed, remove the aria-describedby attribute entirely rather than leaving a broken reference.
Verify all IDs in a multi-value list. If aria-describedby contains multiple space-separated IDs, confirm each one exists.

Examples

Broken reference (triggers the error)

In this example, aria-describedby points to password-help, but no element with that id exists in the document:

<labelfor="password">Password</label>

<inputtype="password"id="password"aria-describedby="password-help">

Fixed by adding the referenced element

Adding an element with id="password-help" resolves the issue:

<labelfor="password">Password</label>

<inputtype="password"id="password"aria-describedby="password-help">

<pid="password-help">Must be at least 8 characters with one number.</p>

Broken reference due to a typo

Here the aria-describedby value uses a different case than the element's id:

<inputtype="text"id="email"aria-describedby="emailHelp">

<smallid="emailhelp">We'll never share your email.</small>

The fix is to make the id values match exactly:

<inputtype="text"id="email"aria-describedby="email-help">

<smallid="email-help">We'll never share your email.</small>

Multiple IDs with one missing

When listing multiple descriptions, every id must be present:

<inputtype="text"id="username"aria-describedby="format-hint length-hint">

<spanid="format-hint">Letters and numbers only.</span>

Fix it by adding the missing element:

<inputtype="text"id="username"aria-describedby="format-hint length-hint">

<spanid="format-hint">Letters and numbers only.</span>

<spanid="length-hint">Between 3 and 20 characters.</span>

Removing the attribute when no description is needed

If the descriptive content has been removed and is no longer relevant, simply remove the aria-describedby attribute:

<inputtype="text"id="search">

The “aria-controls” attribute must point to an element in the same document.

The aria-controls attribute establishes a programmatic relationship between a controlling element (like a button, tab, or scrollbar) and the element it controls (like a panel, region, or content area). Assistive technologies such as screen readers use this relationship to help users navigate between related elements — for example, announcing that a button controls a specific panel and allowing the user to jump to it.

When the id referenced in aria-controls doesn't exist in the document, the relationship is broken. Screen readers may attempt to locate the target element and fail silently, or they may announce a control relationship that leads nowhere. This degrades the experience for users who rely on assistive technology and violates the WAI-ARIA specification, which requires that the value of aria-controls be a valid ID reference list pointing to elements in the same document.

Common causes of this error include:

Typos in the id or the aria-controls value.
Dynamically generated content where the controlled element hasn't been rendered yet or has been removed from the DOM.
Copy-paste errors where aria-controls was copied from another component but the corresponding id was not updated.
Referencing elements in iframes or shadow DOM, which are considered separate document contexts.

The aria-controls attribute accepts one or more space-separated ID references. Every listed ID must match an element in the same document.

How to Fix

Verify the target element exists in the document and has the exact id that aria-controls references.
Check for typos — ID matching is case-sensitive, so mainPanel and mainpanel are not the same.
If the controlled element is added dynamically, ensure it is present in the DOM before or at the same time as the controlling element, or update aria-controls programmatically when the target becomes available.
If the controlled element is genuinely absent (e.g., conditionally rendered), remove the aria-controls attribute until the target element exists.

Examples

Incorrect: `aria-controls` references a non-existent ID

<buttonaria-controls="info-panel"aria-expanded="false">

Toggle Info

</button>

<divid="infopanel">

<p>Here is some additional information.</p>

</div>

This triggers the error because aria-controls="info-panel" does not match the actual id of "infopanel" (note the missing hyphen).

Correct: `aria-controls` matches an existing element's ID

<buttonaria-controls="info-panel"aria-expanded="false">

Toggle Info

</button>

<divid="info-panel">

<p>Here is some additional information.</p>

</div>

Correct: Tab and tab panel relationship

<divrole="tablist">

<buttonrole="tab"aria-controls="tab1-panel"aria-selected="true">

Overview

</button>

<buttonrole="tab"aria-controls="tab2-panel"aria-selected="false">

Details

</button>

</div>

<divid="tab1-panel"role="tabpanel">

<p>Overview content goes here.</p>

</div>

<divid="tab2-panel"role="tabpanel"hidden>

<p>Details content goes here.</p>

</div>

Both aria-controls values — tab1-panel and tab2-panel — correctly correspond to elements present in the document.

Correct: Custom scrollbar controlling a region

<divrole="scrollbar"aria-controls="main-content"aria-valuenow="0"aria-valuemin="0"aria-valuemax="100"aria-orientation="vertical"></div>

<divid="main-content"role="region"aria-label="Main content">

<p>Scrollable content goes here.</p>

</div>

Correct: Controlling multiple elements

The aria-controls attribute can reference multiple IDs separated by spaces. Each ID must exist in the document.

<buttonaria-controls="section-a section-b">

Expand All Sections

</button>

<divid="section-a">

<p>Section A content.</p>

</div>

<divid="section-b">

<p>Section B content.</p>

</div>

CSS: “background”: “from” is not a valid color 3 or 6 hexadecimals numbers.

The background CSS property accepts a variety of value types: named colors (red, blue), hexadecimal codes (#fff, #ff0000), color functions (rgb(), hsl(), rgba()), gradient functions (linear-gradient(), radial-gradient()), image URLs, and CSS keywords like none, transparent, or inherit. The word from is not among these valid values.

Why this happens

This error most commonly appears in one of these scenarios:

Legacy WebKit gradient syntax. Older versions of Safari and Chrome used a proprietary syntax: -webkit-gradient(linear, left top, right top, from(#fff), to(#000)). The from() and to() functions are part of this deprecated, non-standard format. If this syntax is used without the -webkit- prefix—or if the validator encounters it—the word from gets flagged as an invalid color value.
Incorrectly written gradient shorthand. Some developers unfamiliar with the CSS gradient specification write something resembling natural language, like background: from #fff to #000, which has no meaning in CSS.
CSS from keyword in relative color syntax. CSS Color Level 5 introduces relative color syntax using the from keyword (e.g., rgb(from red r g b / 50%)). This is a newer feature that may not yet be recognized by the W3C CSS validator, which can lag behind the latest specifications. If you're using this syntax intentionally, the error may be a false positive from the validator, but be aware that browser support may still be limited.

Why it matters

Invalid CSS values are silently ignored by browsers, meaning your intended background styling won't be applied. The element will fall back to its default or inherited background, which can result in broken layouts, missing visual cues, or poor contrast that harms readability and accessibility. Using standard, valid CSS ensures consistent rendering across all browsers.

How to fix it

Replace legacy -webkit-gradient() syntax with the standard linear-gradient() or radial-gradient() functions.
Use valid color formats for solid backgrounds: hex codes, named colors, or color functions.
If using relative color syntax (from keyword in CSS Color Level 5), understand that the validator may not yet support it. Consider adding a fallback value for broader compatibility.

Examples

Incorrect: legacy WebKit gradient syntax

The from() and to() functions in -webkit-gradient() are non-standard and will trigger this error if used as a background value:

<style>

.banner{

/* Non-standard syntax; "from" is not a valid CSS value */

background:-webkit-gradient(linear, left top, right top,from(#fff),to(#000));

}

</style>

<divclass="banner">Legacy gradient</div>

Incorrect: made-up gradient shorthand

Writing gradient-like syntax without a proper CSS function is invalid:

<style>

.banner{

/* "from" and "to" are not valid CSS keywords here */

background: from #fff to #000;

}

</style>

<divclass="banner">Invalid gradient</div>

Correct: standard linear gradient

Use linear-gradient() with a direction and comma-separated color stops:

<style>

.banner{

background:linear-gradient(to right,#fff,#000);

}

</style>

<divclass="banner">Standard gradient</div>

Correct: solid color background

For a simple solid color, use any valid CSS color value:

<style>

.banner{

background:#fff;

}

</style>

<divclass="banner">White background</div>

Correct: gradient with a fallback for older browsers

When using gradients, it's good practice to provide a solid color fallback:

<style>

.banner{

background:#fff;

background:linear-gradient(to bottom,#ffffff,#cccccc);

}

</style>

<divclass="banner">Gradient with fallback</div>

Correct: relative color syntax with a fallback

If you intentionally use CSS Color Level 5 relative color syntax and the validator flags from, provide a fallback and be aware of current browser support:

<style>

.banner{

background:rgb(255,0,0);

background:rgb(from red r g b /50%);

}

</style>

<divclass="banner">Relative color with fallback</div>

Always verify that your background values use standard CSS syntax. When in doubt, test your styles in the W3C CSS Validator and check browser support on Can I Use.

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.

The “aria-labelledby” attribute must point to an element in the same document.

aria-labelledby

The aria-labelledby attribute creates a relationship between an element and the text content that labels it. It works by pointing to the id of one or more elements whose text should be used as the accessible name. When the validator reports that aria-labelledby must point to an element in the same document, it means at least one of the id values you referenced doesn't correspond to any element on the page.

This typically happens for a few reasons:

Typo in the id — the aria-labelledby value doesn't exactly match the target element's id (remember, IDs are case-sensitive).
The referenced element was removed — the labeling element existed at some point but was deleted or moved, and the reference wasn't updated.
The id exists in a different document — aria-labelledby cannot reference elements across pages, iframes, or shadow DOM boundaries. The target must be in the same document.
Dynamic content not yet rendered — the element is inserted by JavaScript after the validator parses the static HTML.

This is primarily an accessibility problem. Screen readers and other assistive technologies rely on aria-labelledby to announce meaningful labels to users. When the reference is broken, the element effectively has no accessible name, which can make it impossible for users to understand its purpose. Browsers won't throw a visible error, so the issue can go unnoticed without validation or accessibility testing.

To fix the issue, verify that every id referenced in aria-labelledby exists in the same HTML document. Double-check spelling and casing. If you reference multiple IDs (space-separated), each one must resolve to an existing element.

Examples

Incorrect — referencing a non-existent `id`

The aria-labelledby attribute points to "dialog-title", but no element with that id exists:

<divrole="dialog"aria-labelledby="dialog-title">

<h2id="dlg-title">Confirm deletion</h2>

<p>Are you sure you want to delete this item?</p>

</div>

Correct — matching `id` values

Ensure the id in the referenced element matches exactly:

<divrole="dialog"aria-labelledby="dialog-title">

<h2id="dialog-title">Confirm deletion</h2>

<p>Are you sure you want to delete this item?</p>

</div>

Incorrect — referencing multiple IDs where one is missing

When using multiple IDs, every one must be present. Here, "note-desc" doesn't exist:

<sectionaria-labelledby="note-heading note-desc">

<h3id="note-heading">Important note</h3>

<pid="note-description">Please read carefully before proceeding.</p>

</section>

Correct — all referenced IDs exist

<sectionaria-labelledby="note-heading note-description">

<h3id="note-heading">Important note</h3>

<pid="note-description">Please read carefully before proceeding.</p>

</section>

Incorrect — case mismatch

IDs are case-sensitive. "Main-Title" and "main-title" are not the same:

<navaria-labelledby="Main-Title">

<h2id="main-title">Site navigation</h2>

<ul>

</ul>

</nav>

Correct — consistent casing

<navaria-labelledby="main-title">

<h2id="main-title">Site navigation</h2>

<ul>

</ul>

</nav>

If you don't have a visible labeling element on the page and don't want to add one, consider using aria-label instead, which accepts a string value directly rather than referencing another element:

<navaria-label="Site navigation">

<ul>

</ul>

</nav>

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: 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: 500.

Attribute with the local name “xmlns:(fb|og)” is not serializable as XML 1.0

Understanding the Issue

In the early days of the Open Graph Protocol (used by Facebook, LinkedIn, and other platforms to parse shared links), developers were instructed to add XML namespace declarations like xmlns:og and xmlns:fb to the <html> element. This was borrowed from XHTML conventions where custom prefixed attributes required namespace bindings.

However, modern HTML5 documents are not XML. The HTML5 parser does not support arbitrary namespace declarations in the way XHTML/XML does. Attributes with colons in their local names (like xmlns:og) are not serializable as XML 1.0, meaning they cannot be reliably round-tripped between HTML and XML parsers. The W3C validator flags this because these attributes violate the HTML serialization rules.

The good news is that these namespace declarations have never been required for Open Graph tags to work. Social media crawlers (Facebook's, Twitter's, LinkedIn's, etc.) parse <meta> tags based on the property attribute value directly — they don't rely on XML namespace resolution. Browsers also ignore these attributes entirely, so removing them has zero impact on functionality.

How to Fix It

Locate your <html> opening tag.
Remove any xmlns:og, xmlns:fb, or similar namespace attributes.
Keep your Open Graph <meta> tags exactly as they are — they will continue to work.

Examples

❌ Incorrect: Namespace attributes on the `<html>` element

<!DOCTYPE html>

<htmllang="en"xmlns:og="http://ogp.me/ns#"xmlns:fb="http://www.facebook.com/2008/fbml">

<head>

<metaproperty="og:title"content="My Page Title">

<metaproperty="og:description"content="A description of my page.">

<metaproperty="og:image"content="https://example.com/image.jpg">

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

This triggers the validator warning: Attribute with the local name "xmlns:og" is not serializable as XML 1.0 (and similarly for xmlns:fb).

✅ Correct: Clean `<html>` element without namespace attributes

<!DOCTYPE html>

<htmllang="en">

<head>

<metaproperty="og:title"content="My Page Title">

<metaproperty="og:description"content="A description of my page.">

<metaproperty="og:image"content="https://example.com/image.jpg">

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

The Open Graph <meta> tags remain unchanged and will continue to be recognized by Facebook, LinkedIn, and all other platforms that support the Open Graph Protocol. The only change is removing the unnecessary xmlns:og and xmlns:fb attributes from the <html> tag.

Common Variations

You may also encounter other namespace prefixes like xmlns:article, xmlns:product, or xmlns:music. These are all unnecessary in HTML5 and should be removed:

<htmllang="en"xmlns:og="http://ogp.me/ns#"xmlns:article="http://ogp.me/ns/article#"xmlns:fb="http://www.facebook.com/2008/fbml">

<htmllang="en">

Note that the standard xmlns attribute (without a colon prefix) is allowed on the <html> element in HTML5 if its value is exactly http://www.w3.org/1999/xhtml. However, even this is unnecessary and can be omitted. The prefixed forms like xmlns:og are never valid in HTML5.

A document must not include both a “meta” element with an “http-equiv” attribute whose value is “content-type”, and a “meta” element with a “charset” attribute.

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>

<htmllang="en">

<head>

<metacharset="UTF-8">

<metahttp-equiv="content-type"content="text/html; charset=UTF-8">

</head>

<body>

<p>Hello, world!</p>

</body>

</html>

Correct: using `<meta charset>` (recommended)

This is the modern, preferred approach for HTML5 documents.

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="UTF-8">

</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>

<htmllang="en">

<head>

<metahttp-equiv="content-type"content="text/html; charset=UTF-8">

</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.

<head>

<metacharset="UTF-8">

</head>

<metahttp-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>.

How to Fix

Examples

Incorrect: Office namespace attributes on the <html> element

Correct: Clean HTML5 without Office namespaces

Incorrect: Office namespace on a non-root element

Correct: Cleaned-up version

Why This Matters

How to Fix It

Examples

❌ Invalid: Empty poster attribute

✅ Fixed: Poster attribute with a valid URL

✅ Fixed: Poster attribute removed entirely

✅ Fixed: Conditional rendering in a template

Valid values

Common causes

Examples

Incorrect: invalid keyword

Incorrect: missing unit on a length

Incorrect: malformed repeat() syntax

Correct: using fr units

Correct: mixing lengths, fr, and auto

Correct: using repeat() and minmax()

Correct: named grid lines with track sizes

How to Fix

Examples

❌ Invalid: Empty action attribute

✅ Fixed: Remove the action attribute

✅ Fixed: Provide a valid URL

✅ Fixed: Use a hash as a placeholder for JavaScript-handled forms

How to Fix It

Examples

❌ Invalid: Empty src attribute

❌ Invalid: Whitespace-only src attribute

✅ Fixed: Valid external script

✅ Fixed: Valid external script with a full URL

✅ Fixed: Inline script without src

✅ Fixed: Conditionally omitting the element

Why this matters

How to fix it

Examples

Incorrect: legacy VML namespace declaration

Correct: namespace removed, VML replaced with SVG

Correct: simple removal when no vector graphics are needed

HTML Examples

Before: referencing an unreachable remote resource

After: hosting locally or using a reliable CDN

Understanding the 502 Bad Gateway Error

Common Causes

How to Fix It

Alternatives When Your Server Is Unavailable

Validate by Direct Input

Validate by File Upload

Examples

A valid HTML page that the validator cannot reach

Examples

Invalid hex color values

Valid hex color values

Alternative color formats

Common Causes

How to Fix It

Wait and retry

Reduce validation frequency

Host resources locally

Adjust server rate limits

Examples

Page that may trigger the issue

Fix: Self-host the resources

Fix: Reduce external dependencies

Common causes

Direct placement in <body>

Implicit <body> creation by the parser

How to fix it

Examples

❌ <link rel="canonical"> placed in <body>

✅ Move it to <head>

❌ An <img> in <head> forces implicit body context

✅ Move the <img> to <body> where it belongs

✅ Allowed <link> elements inside <body>

✅ Using itemprop for microdata

Incorrect: Office namespace attributes on the `<html>` element

❌ Invalid: Empty `poster` attribute

Incorrect: malformed `repeat()` syntax

Correct: using `fr` units

Correct: mixing lengths, `fr`, and `auto`

Correct: using `repeat()` and `minmax()`

❌ Invalid: Empty `action` attribute

✅ Fixed: Remove the `action` attribute

❌ Invalid: Empty `src` attribute

❌ Invalid: Whitespace-only `src` attribute

✅ Fixed: Inline script without `src`

Direct placement in `<body>`

Implicit `<body>` creation by the parser

❌ `<link rel="canonical">` placed in `<body>`

✅ Move it to `<head>`

❌ An `<img>` in `<head>` forces implicit body context

✅ Move the `<img>` to `<body>` where it belongs

✅ Allowed `<link>` elements inside `<body>`

✅ Using `itemprop` for microdata

Incorrect: `aria-controls` references a non-existent ID

Correct: `aria-controls` matches an existing element's ID

Incorrect — referencing a non-existent `id`

Correct — matching `id` values