HTML Guides

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

An “li” element that is a descendant of a “role=listbox” element or “role=list” element must not have any “role” value other than “group” or “option”.

Only “0” can be a “unit”. You must put a unit after your number

css
units

In CSS, most numeric values represent a length, time, angle, or other dimension, and the unit tells the browser how to interpret the number. Writing padding: 20 is ambiguous — does it mean 20 pixels, 20 ems, or 20 percent? Without a unit, the browser has no way to determine the author's intent, so it treats the value as invalid and discards the entire declaration. This can lead to broken layouts, missing spacing, or other visual problems that are difficult to debug.

The only exception to this rule is 0. Zero pixels is the same as zero ems, zero rems, or zero percent — it's always nothing regardless of the unit. Because of this, the CSS specification allows 0 to be written without a unit. In fact, omitting the unit on zero values is considered a best practice for cleaner, more concise CSS.

This validation error commonly appears in inline style attributes, which is where the W3C HTML Validator encounters it. However, the same rule applies to CSS written in <style> elements and external stylesheets.

Common causes of this error include:

Accidentally forgetting to type the unit after a number.
Copy-pasting values from design tools that don't include units.
Confusing CSS with JavaScript's element.style.width = "50" pattern (where some APIs accept unitless numbers).
Assuming that px is the default unit (it is not — there is no default unit in CSS).

Examples

Incorrect — missing units on numeric values

<divstyle="margin:10;padding:20;width:300;">

Content here

</div>

The validator will report errors for 10, 20, and 300 because none of them have units.

Correct — units specified on all non-zero values

<divstyle="margin:10px;padding:20px;width:300px;">

Content here

</div>

Correct — zero without a unit

<divstyle="margin:0;padding:0;border:0;">

No units needed for zero

</div>

Correct — mixing zero and non-zero values

<divstyle="margin:010px020px;">

Top and bottom margins are zero, sides have units

</div>

Correct — using other unit types

<pstyle="font-size:1.2em;line-height:1.5em;margin-bottom:2rem;">

Text with relative units

</p>

Note that line-height is a special case in CSS — it actually accepts a unitless number (like 1.5) as a valid value, where the number acts as a multiplier of the element's font size. This is not the same as a missing unit; it's a deliberately unitless ratio defined in the specification. Most other properties do not have this behavior.

The “base” element must come before any “link” or “script” elements in the document.

The “sizes” attribute must only be specified if the “srcset” attribute is also specified.

sizes
srcset

The sizes attribute and the srcset attribute are designed to work as a pair for responsive image delivery. The srcset attribute provides the browser with a list of image files and their intrinsic widths (e.g., 480w, 800w), while the sizes attribute tells the browser how much space the image will occupy in the layout at different viewport sizes. The browser combines this information to select the most appropriate image file to download.

When sizes appears without srcset, it serves no purpose. The browser has only the single image specified in the src attribute, so there's no decision to make about which image to load. The HTML specification explicitly requires that sizes must not be present unless srcset is also specified with width descriptors.

This error commonly occurs when a CMS or templating system outputs the sizes attribute by default, when srcset is accidentally removed during refactoring, or when developers copy markup snippets without including all the necessary attributes.

Beyond standards compliance, leaving orphaned sizes attributes creates confusing, harder-to-maintain code. Other developers (or your future self) may assume responsive images are configured when they aren't, leading to wasted debugging time.

How to fix it

You have two options:

Add a srcset attribute if you want the browser to choose from multiple image sizes based on viewport width. The srcset must use width descriptors (w) for sizes to be meaningful.
Remove the sizes attribute if you don't need responsive images and a single src is sufficient.

Note that sizes is also valid on <source> elements inside a <picture> element — the same rule applies there. Every <source> with a sizes attribute must also have a srcset attribute.

Examples

❌ Incorrect: `sizes` without `srcset`

<img

src="image.jpg"

sizes="(max-width: 600px) 480px, 800px"

alt="A mountain landscape">

The sizes attribute is present but there's no srcset, so the browser has no alternative images to pick from.

✅ Correct: `sizes` paired with `srcset`

<img

src="image-800w.jpg"

srcset="image-480w.jpg 480w, image-800w.jpg 800w"

sizes="(max-width: 600px) 480px, 800px"

alt="A mountain landscape">

Here, srcset provides two images with their intrinsic widths. The sizes attribute tells the browser: "If the viewport is 600px or narrower, the image will display at 480px wide; otherwise, it will display at 800px wide." The browser uses this information to download the most efficient file.

✅ Correct: removing `sizes` when responsive images aren't needed

<imgsrc="image.jpg"alt="A mountain landscape">

If a single image is sufficient, simply drop the sizes attribute.

❌ Incorrect: `sizes` on a `<source>` without `srcset`

<source

media="(min-width: 800px)"

sizes="50vw">

<imgsrc="fallback.jpg"alt="A sunset over the ocean">

</picture>

✅ Correct: `sizes` on a `<source>` with `srcset`

<source

media="(min-width: 800px)"

srcset="wide-480w.jpg 480w, wide-960w.jpg 960w"

sizes="50vw">

<imgsrc="fallback.jpg"alt="A sunset over the ocean">

</picture>

The <source> element now includes a srcset with width descriptors, giving the browser the candidate images it needs to make use of sizes.

CSS: The value is out of range.This value must be between “0” and “100”'.

CSS

End tag X did not match the name of the current open element Y.

HTML follows strict nesting rules: elements must be closed in the reverse order they were opened, like a stack. When the validator encounters </X> but the current open element is Y, it means something has gone wrong in the document structure. The browser's parser will attempt to recover from this mismatch, but the result may not reflect your intended layout or semantics.

There are several common causes for this error:

Typos in tag names — for example, opening a <div> but closing it with </dvi>.
Mismatched tags — opening one element but closing a different one, such as <strong> closed with </em>.
Incorrect nesting order — overlapping elements where tags cross boundaries instead of being properly nested.
Missing closing tags — a forgotten closing tag causes subsequent closing tags to be misaligned with the parser's expectation.

This matters because improperly nested HTML can cause unpredictable rendering across browsers, break CSS styling, interfere with JavaScript DOM manipulation, and create accessibility problems for screen readers that rely on a well-formed document tree.

To fix this error, trace back from the reported line to find where the mismatch originates. Ensure that every opening tag has a corresponding closing tag with the exact same name, and that elements are closed in the correct order (last opened, first closed).

Examples

Typo in the closing tag

<p>Hello world</p>

</secton>

<p>Hello world</p>

</section>

Mismatched tags

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

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

Incorrectly nested (overlapping) elements

<p><b>Bold <i>and italic</b> text</i></p>

The validator sees </b> when the current open element is <i>. Elements must nest completely inside one another without overlapping.

<p><b>Bold <i>and italic</i></b><i> text</i></p>

Missing closing tag causing a cascade of errors

<divclass="outer">

<divclass="inner">

<p>Content</p>

</div>

Here the single </div> closes inner, leaving outer unclosed. If more HTML follows, subsequent closing tags will be misaligned, potentially producing this error further down in the document.

<divclass="outer">

<divclass="inner">

<p>Content</p>

</div>

Tips for debugging

Work from the first error — in HTML validation, one early mistake can cascade into many subsequent errors. Fix the first reported mismatch and re-validate before tackling later errors.
Use consistent indentation — properly indented code makes it much easier to spot where nesting goes wrong.
Use an editor with bracket/tag matching — most code editors can highlight matching opening and closing tags, making mismatches immediately visible.

The “type” attribute for the “style” element is not needed and should be omitted.

In earlier versions of HTML (HTML 4 and XHTML), the type attribute was required on the <style> element to declare the MIME type of the styling language being used. The value was almost always text/css, as CSS has been the dominant stylesheet language for the web since its inception.

With HTML5, the specification changed. The type attribute on <style> now defaults to text/css, and since no browser supports any other styling language, the attribute serves no practical purpose. The WHATWG HTML Living Standard explicitly notes that the attribute is unnecessary and can be omitted. The W3C validator flags its presence as a warning to encourage cleaner, more modern markup.

Why This Matters

Cleaner code: Removing unnecessary attributes reduces file size (even if marginally) and improves readability. Every attribute should earn its place in your markup.
Standards compliance: Modern HTML encourages omitting default values when they add no information. Including type="text/css" signals outdated coding practices.
Consistency: The same principle applies to <script> elements, where type="text/javascript" is also unnecessary. Keeping your markup consistent by omitting both makes your codebase easier to maintain.

How to Fix It

The fix is straightforward: find every <style> element in your HTML that includes a type attribute and remove it. No other changes are needed — the browser behavior will be identical.

If you're working on a large codebase, a simple search for <style type= across your files will help you find all instances.

Examples

❌ Incorrect: Redundant `type` attribute

<styletype="text/css">

p{

color: red;

}

</style>

The type="text/css" attribute is unnecessary and triggers the W3C validator warning.

✅ Correct: `type` attribute omitted

<style>

p{

color: red;

}

</style>

Without the type attribute, the browser still interprets the contents as CSS — the behavior is exactly the same.

❌ Incorrect: Other variations that also trigger the warning

The warning is triggered regardless of how the type value is formatted:

<styletype="text/css"media="screen">

body{

font-family: sans-serif;

}

</style>

✅ Correct: Other attributes are fine, just remove `type`

<stylemedia="screen">

body{

font-family: sans-serif;

}

</style>

Note that other valid attributes like media or nonce should be kept — only the type attribute needs to be removed.

A “script” element with a “src” attribute must not have a “type” attribute whose value is anything other than the empty string, a JavaScript MIME type, or “module”.

The <script> element serves two distinct purposes in HTML: loading executable scripts and embedding non-executable data blocks. When the src attribute is present, the element is always being used to load an external script, so the type attribute must reflect a valid script type. Setting type to something like "text/html", "text/plain", or an invented value like "wrong" tells the browser this is not JavaScript, which means the external file referenced by src will be fetched but never executed — almost certainly not what the author intended.

The HTML specification restricts the allowed type values for <script src="..."> to three categories:

An empty string (type=""): Treated the same as the default, which is JavaScript.
A JavaScript MIME type: This includes text/javascript, application/javascript, and other legacy JavaScript MIME types. Since text/javascript is the default, specifying it is redundant.
module: Indicates the script should be treated as a JavaScript module, enabling import/export syntax and deferred execution by default.

Any value outside these categories — such as text/html, application/json, or a made-up string — is invalid when src is present.

Why this matters

Broken functionality: A non-JavaScript type on a <script> with src prevents the browser from executing the loaded file. The script is effectively dead code that still costs a network request.

Standards compliance: The HTML living standard explicitly forbids this combination. Validators flag it because it almost always indicates a mistake — either the wrong type was applied, or the src attribute was added by accident.

Maintainability: Future developers reading the code may be confused about whether the script is supposed to execute or serve as an inert data block. Keeping markup valid makes intent clear.

How to fix it

Remove the type attribute entirely. This is the best approach for classic JavaScript. The default behavior is text/javascript, so no type is needed.
Use type="module" if the script uses ES module syntax (import/export).
If you intended a data block (e.g., embedding JSON or a template), remove the src attribute and place the content inline inside the <script> element instead. Data blocks with non-JavaScript types cannot use src.

Examples

Invalid: non-JavaScript types with `src`

These all trigger the validation error because the type value is not a JavaScript MIME type, an empty string, or "module":

<scripttype="text/html"src="template.html"></script>

<scripttype="application/json"src="data.json"></script>

<scripttype="text/plain"src="app.js"></script>

<scripttype="wrong"src="app.js"></script>

Valid: omitting the `type` attribute

The simplest and recommended fix for classic scripts — just drop type:

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

Valid: using a JavaScript MIME type

This is valid but redundant, since text/javascript is already the default. The validator may suggest omitting it:

<scripttype="text/javascript"src="app.js"></script>

Valid: using `type="module"`

Use this when the external script uses ES module syntax:

<scripttype="module"src="app.js"></script>

Valid: using an empty `type` attribute

An empty string is treated as the default. It's valid but unnecessary, and the validator may suggest removing it:

<scripttype=""src="app.js"></script>

Valid: data blocks without `src`

If you need a non-JavaScript type for an inline data block, remove the src attribute and place the content directly inside the element:

<scripttype="application/json"id="config">

{

"apiUrl":"https://example.com/api",

"debug":false

}

</script>

X-UA-Compatible HTTP header must have the value “IE=edge”, was “IE=10”.

X-UA-Compatible

The X-UA-Compatible directive was introduced to control which rendering engine Internet Explorer would use when displaying a page. Setting it to a specific version like IE=10 locks the page into that version's rendering mode, even if the user has a newer version of Internet Explorer installed. This is problematic because it prevents the browser from using its most capable, standards-compliant rendering engine and can lead to unexpected layout or functionality issues.

The value IE=edge tells Internet Explorer to use the latest rendering engine available, which ensures the best possible standards compliance and feature support. The HTML specification and the W3C validator enforce this requirement because pinning to a specific IE version serves no forward-compatible purpose and can actively degrade the browsing experience.

It's worth noting that with Internet Explorer now being retired and replaced by Microsoft Edge, this meta tag is largely historical. However, if you include it at all, the validator requires that it be set to IE=edge. If your site no longer needs to support legacy versions of Internet Explorer, you can also simply remove the X-UA-Compatible declaration entirely — modern browsers ignore it.

How to fix it

Find any <meta http-equiv="X-UA-Compatible"> tag in your HTML <head>.
Change the content attribute value from the specific version (e.g., IE=10) to IE=edge.
If the directive is set as an HTTP response header on your server, update the header value there as well.
Alternatively, remove the tag or header entirely if you no longer need IE compatibility.

Examples

Incorrect: pinned to a specific IE version

This triggers the validator error because IE=10 locks rendering to Internet Explorer 10 mode:

<metahttp-equiv="X-UA-Compatible"content="IE=10">

Other version-specific values that would also trigger this error include IE=9, IE=11, IE=EmulateIE10, and similar variations.

Correct: using `IE=edge`

Replace the version-specific value with IE=edge:

<metahttp-equiv="X-UA-Compatible"content="IE=edge">

Correct: full document example

When included in a complete HTML document, the X-UA-Compatible meta tag should appear early in the <head>, ideally right after the <meta charset> declaration:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

<metahttp-equiv="X-UA-Compatible"content="IE=edge">

</head>

<body>

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

</body>

</html>

Correct: removing the tag entirely

If IE support is no longer a concern, the simplest fix is to remove the meta tag altogether:

<!DOCTYPE html>

<htmllang="en">

<head>

<metacharset="utf-8">

</head>

<body>

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

</body>

</html>

Server-side HTTP header

If the X-UA-Compatible value is being sent as an HTTP response header rather than a meta tag, update your server configuration. For example, in Apache:

# Incorrect

Header set X-UA-Compatible "IE=10"

# Correct

Header set X-UA-Compatible "IE=edge"

Or in Nginx:

# Incorrect

add_header X-UA-Compatible "IE=10";

# Correct

add_header X-UA-Compatible "IE=edge";

CSS: @import are not allowed after any valid statement other than @charset and @import.

css
import

The @import rule allows you to pull in styles from another CSS file. According to the CSS specification, @import rules must precede all other at-rules (except @charset) and all style rules. When a browser encounters an @import after another valid CSS statement, it silently ignores the import. This means the styles you intended to load simply won't be applied, which can lead to broken layouts or missing designs that are difficult to debug.

The W3C validator catches this ordering problem and flags it because the misplaced @import will have no effect. Even though browsers won't throw a visible error, the imported stylesheet is completely discarded, making this a real functional issue rather than just a cosmetic validation warning.

The correct order inside a <style> element or CSS file is:

@charset (if needed, and only in external CSS files)
@import rules
All other CSS rules (@font-face, @media, style rules, etc.)

Examples

Incorrect: `@import` after a style rule

<style>

body{

margin:0;

}

@importurl("typography.css");

h1{

color: navy;

}

</style>

The @import is placed after the body rule, so the browser will ignore it entirely. The styles from typography.css will never be loaded.

Incorrect: `@import` after another at-rule

<style>

@font-face{

font-family:"MyFont";

src:url("myfont.woff2")format("woff2");

}

@importurl("reset.css");

</style>

Even though @font-face is an at-rule, it is not @charset or @import, so placing @import after it is invalid.

Correct: `@import` rules first

<style>

@importurl("reset.css");

@importurl("typography.css");

@font-face{

font-family:"MyFont";

src:url("myfont.woff2")format("woff2");

}

body{

margin:0;

}

h1{

color: navy;

}

</style>

All @import rules appear before any other statements, so they are valid and the imported stylesheets will be loaded correctly.

Correct: Multiple `@import` rules with `@charset`

In an external CSS file, you may also have a @charset declaration. It must come first, followed by @import rules:

@charset"UTF-8";

@importurl("base.css");

@importurl("components.css");

body{

font-family: sans-serif;

}

Alternatives to `@import`

While fixing the ordering resolves the validation error, it's worth noting that @import in CSS can cause performance issues because imported files are loaded sequentially rather than in parallel. Consider these alternatives:

Multiple <link> elements in your HTML <head> — these allow browsers to download stylesheets in parallel.
CSS bundling tools — build tools like Webpack, Vite, or PostCSS can combine multiple CSS files into one at build time, eliminating the need for @import at runtime.

If you do use @import, just make sure every instance appears at the very top of your stylesheet, before any other CSS rules.

A “script” element with a “type” attribute whose value is neither a JavaScript MIME type, “module”, “importmap”, nor “speculationrules” (i.e., a data block) must not have an “async” attribute.

A “script” element with a “type” attribute whose value is neither a JavaScript MIME type, “module”, “importmap”, nor “speculationrules” (i.e., a data block) must not have a “defer” attribute.

Bad value for attribute “href” on element “a”: Illegal character in fragment: “|” is not allowed.

Bad value for attribute “href” on element “a”: Illegal character in query. “|” is not allowed.

Element “input” with attribute “type” whose value is “button” must have non-empty attribute “value”.

The “itemprop” attribute was specified, but the element is not a property of any item.

Microdata is an HTML specification that lets you embed machine-readable data into your content using three main attributes: itemscope, itemtype, and itemprop. The itemscope attribute creates a new item (a group of name-value pairs), itemtype specifies what kind of thing the item is (using a vocabulary URL like Schema.org), and itemprop defines individual properties within that item. These attributes work together — itemprop only makes sense in the context of an itemscope.

When the validator encounters an itemprop attribute on an element that isn't a descendant of any element with itemscope, it has no way to associate that property with an item. The property is essentially orphaned. This is a problem for several reasons:

Search engines can't use the data. Structured data consumers like Google, Bing, and other crawlers rely on the itemscope/itemprop hierarchy to understand your content. An orphaned itemprop is ignored or misinterpreted.
Standards compliance. The WHATWG HTML living standard requires that an element with itemprop must be a property of an item — meaning it must have an ancestor with itemscope, or be explicitly referenced via the itemref attribute on an itemscope element.
Maintenance issues. Orphaned itemprop attributes suggest that surrounding markup was refactored and the microdata structure was accidentally broken.

The most common causes of this error are:

Missing itemscope — You added itemprop attributes but forgot to define the containing item with itemscope.
Moved elements — An element with itemprop was moved outside of its original itemscope container during a refactor.
Copy-paste errors — You copied a snippet that included itemprop but not the parent itemscope.

To fix the issue, either wrap the itemprop elements inside an itemscope container, use itemref to associate distant properties with an item, or remove the itemprop attribute if structured data is not intended.

Examples

Incorrect: `itemprop` without `itemscope`

This triggers the validation error because there is no itemscope ancestor:

<div>

</div>

Correct: `itemprop` inside an `itemscope` container

Adding itemscope (and optionally itemtype) to an ancestor element fixes the issue:

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

</div>

Correct: nested items with their own scope

When an item contains a sub-item, the nested item needs its own itemscope:

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

<pitemprop="name">Liza</p>

<divitemprop="address"itemscopeitemtype="https://schema.org/PostalAddress">

<spanitemprop="addressLocality">Portland</span>,

<spanitemprop="addressRegion">OR</span>

</div>

Correct: using `itemref` for properties outside the scope

If you can't restructure your HTML to nest itemprop inside itemscope, use itemref to reference elements by their id:

<divitemscopeitemtype="https://schema.org/Person"itemref="user-name"></div>

<pid="user-name">

My name is <spanitemprop="name">Liza</span>.

</p>

In this case, the itemprop="name" element is not a descendant of the itemscope element, but the itemref="user-name" attribute explicitly pulls the referenced element's tree into the item, making it valid.

Incorrect: scope broken after refactoring

A common real-world scenario where the error appears after restructuring:

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

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

</div>

<spanitemprop="price">9.99</span>

Fix this by either moving the element back inside the itemscope container, using itemref, or removing the orphaned itemprop.

Bad value for attribute “href” on element “a”: Illegal character in fragment: “#” is not allowed.

In a URL, the # character has a special role: it acts as the delimiter that separates the main URL from the fragment identifier. The fragment typically points to a specific section or element within the target document, often corresponding to an element's id attribute. Because # serves this reserved purpose, it cannot appear more than once in its raw form within a URL. When the validator encounters something like ##pricing or section#one#two, it flags the extra # characters as illegal.

This issue usually arises from one of these common scenarios:

Typos — accidentally typing ## instead of #.
String concatenation bugs — building URLs programmatically where a # is included both in the base URL and prepended to the fragment value.
Copy-paste errors — duplicating the # when copying URLs from browser address bars or other sources.
Literal # intended in fragment — if you genuinely need a # symbol within the fragment text, it must be percent-encoded as %23.

This matters because browsers may handle malformed URLs inconsistently. Some browsers silently strip the extra #, while others may fail to navigate to the intended fragment. Malformed URLs also cause problems for assistive technologies, web crawlers, and any tooling that parses links. Keeping your URLs well-formed ensures predictable behavior across all user agents and complies with the URL Standard and HTML specification.

Examples

Incorrect: duplicate `#` in the URL

The double ## makes the fragment identifier invalid:

<ahref="https://example.com/faqs##pricing">Pricing</a>

Correct: single `#` delimiter

Remove the extra # so that pricing is the fragment:

<ahref="https://example.com/faqs#pricing">Pricing</a>

Incorrect: extra `#` inside the fragment

Here, the fragment portion overview#details contains a raw #, which is not allowed:

<ahref="/docs#overview#details">Details</a>

Correct: percent-encode the literal `#`

If you truly need a # as part of the fragment text, encode it as %23:

<ahref="/docs#overview%23details">Details</a>

In most cases though, this pattern suggests the URL structure should be rethought. A cleaner approach is to link directly to the intended fragment:

<ahref="/docs#details">Details</a>

Incorrect: programmatic concatenation error

A common bug in templates or JavaScript is prepending # when the variable already includes it:

<ahref="https://example.com/faqs#pricing">Pricing</a>

Correct: ensure only one `#` is present

Make sure either the base URL or the fragment variable includes the #, but not both:

<ahref="https://example.com/faqs#pricing">Pricing</a>

Fragment-only links

Fragment-only links (links to sections within the same page) follow the same rule — only one #:

<ahref="##contact">Contact Us</a>

<ahref="#contact">Contact Us</a>

Bad value for attribute “src” on element “img”: Illegal character in query: “[” is not allowed.

The URL specification (defined by WHATWG and RFC 3986) restricts which characters can appear unencoded in different parts of a URL. Square brackets are reserved characters that have a specific meaning in URLs — they are only permitted in the host portion (to wrap IPv6 addresses like [::1]). In the query string, they must be percent-encoded.

This issue commonly appears when frameworks (especially PHP, Ruby on Rails, or JavaScript libraries) generate URLs with array-style query parameters like ?filter[color]=red. While many browsers and servers are lenient and will interpret these URLs correctly, they are technically invalid according to the URL standard. The W3C validator enforces this rule strictly.

Beyond standards compliance, using unencoded square brackets can cause problems in practice. Some HTTP clients, proxies, or caching layers may reject or mangle URLs containing raw brackets. Percent-encoding these characters ensures your URLs are universally safe and interoperable across all systems.

How to fix it

You have two main approaches:

Percent-encode the brackets. Replace every [ with %5B and every ] with %5D in the URL. This preserves the parameter structure that your server or framework expects, while making the URL valid.
Restructure the query parameters. If your backend allows it, use flat parameter names with dot notation, underscores, or dashes instead of bracket syntax. For example, change size[width] to size_width or size.width.

If you're generating URLs in JavaScript, the built-in encodeURI() function does not encode square brackets. Use encodeURIComponent() on individual parameter names or values, or manually replace [ and ] after constructing the URL.

Examples

❌ Invalid: unencoded square brackets in query string

<imgsrc="/images/photo.jpg?size[width]=300&size[height]=200"alt="A sample photo">

The literal [ and ] characters in the query string trigger the validation error.

✅ Fixed: percent-encoded brackets

<imgsrc="/images/photo.jpg?size%5Bwidth%5D=300&size%5Bheight%5D=200"alt="A sample photo">

Replacing [ with %5B and ] with %5D makes the URL valid. Most servers and frameworks will decode these automatically and interpret the parameters the same way.

✅ Fixed: flat parameter names without brackets

<imgsrc="/images/photo.jpg?size_width=300&size_height=200"alt="A sample photo">

If you control the server-side logic, you can avoid brackets altogether by using a flat naming convention for your parameters.

❌ Invalid: brackets in more complex query strings

<img

src="/api/image?filters[type]=jpeg&filters[quality]=80&crop[x]=10&crop[y]=20"

alt="Processed image">

✅ Fixed: all brackets encoded

<img

src="/api/image?filters%5Btype%5D=jpeg&filters%5Bquality%5D=80&crop%5Bx%5D=10&crop%5By%5D=20"

alt="Processed image">

Encoding in JavaScript

If you build image URLs dynamically, handle the encoding in your code:

// Manual replacement approach

consturl="/images/photo.jpg?size[width]=300&size[height]=200";

constsafeUrl=url.replace(/\[/g,"%5B").replace(/\]/g,"%5D");

img.src=safeUrl;

// Using URLSearchParams (automatically encodes brackets)

constparams=newURLSearchParams();

params.set("size[width]","300");

params.set("size[height]","200");

img.src=`/images/photo.jpg?${params.toString()}`;

Both approaches produce a valid, properly encoded URL that will pass W3C validation.

Invalid example

Valid example

Example with the issue

Fixed example

Common Causes

How to Fix It

1. Verify your site is publicly accessible

2. Check server response time

3. Check firewall and security rules

4. Use direct input as a workaround

Examples

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

Using direct input instead (works)

When to Contact Your Hosting Provider

Common Causes

How to Fix

Examples

Incorrect server behavior (returns 202)

Correct server behavior (returns 200)

Verifying the status code with curl

HTML Examples

Before — referencing an unreachable resource

After — using a valid, accessible URL

Understanding the Issue

How to Fix It

Examples

❌ Incorrect: Namespace attributes on the <html> element

✅ Correct: Clean <html> element without namespace attributes

Common Variations

Examples

Incorrect: both declarations present

Correct: using <meta charset> (recommended)

Correct: using <meta http-equiv="content-type">

Common scenario: declarations split across includes

Invalid example

Valid example

Examples

Incorrect — missing units on numeric values

Correct — units specified on all non-zero values

Correct — zero without a unit

Correct — mixing zero and non-zero values

Correct — using other unit types

Invalid example

Valid example

How to fix it

Examples

❌ Incorrect: sizes without srcset

✅ Correct: sizes paired with srcset

✅ Correct: removing sizes when responsive images aren't needed

❌ Incorrect: sizes on a <source> without srcset

✅ Correct: sizes on a <source> with srcset

HTML Examples

❌ Invalid: value out of range

✅ Fixed: value within range

Examples

Typo in the closing tag

Mismatched tags

Incorrectly nested (overlapping) elements

Missing closing tag causing a cascade of errors

Tips for debugging

Why This Matters

How to Fix It

Examples

❌ Incorrect: Redundant type attribute

✅ Correct: type attribute omitted

❌ Incorrect: Other variations that also trigger the warning

✅ Correct: Other attributes are fine, just remove type

Why this matters

How to fix it

Examples

Invalid: non-JavaScript types with src

Valid: omitting the type attribute

Valid: using a JavaScript MIME type

Valid: using type="module"

Valid: using an empty type attribute

Valid: data blocks without src

How to fix it

Examples

Incorrect: pinned to a specific IE version

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

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

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

Correct: using `<meta http-equiv="content-type">`

❌ Incorrect: `sizes` without `srcset`

✅ Correct: `sizes` paired with `srcset`

✅ Correct: removing `sizes` when responsive images aren't needed

❌ Incorrect: `sizes` on a `<source>` without `srcset`

✅ Correct: `sizes` on a `<source>` with `srcset`

❌ Incorrect: Redundant `type` attribute

✅ Correct: `type` attribute omitted

✅ Correct: Other attributes are fine, just remove `type`

Invalid: non-JavaScript types with `src`

Valid: omitting the `type` attribute

Valid: using `type="module"`

Valid: using an empty `type` attribute

Valid: data blocks without `src`

Correct: using `IE=edge`

Incorrect: `@import` after a style rule

Incorrect: `@import` after another at-rule

Correct: `@import` rules first

Correct: Multiple `@import` rules with `@charset`

Alternatives to `@import`

Invalid: `async` on a data block

Valid: data block without `async`

Invalid: `defer` on a data block

Valid: data block without `defer`

Incorrect: `itemprop` without `itemscope`

Correct: `itemprop` inside an `itemscope` container

Correct: using `itemref` for properties outside the scope

Incorrect: duplicate `#` in the URL

Correct: single `#` delimiter

Incorrect: extra `#` inside the fragment

Correct: percent-encode the literal `#`

Correct: ensure only one `#` is present

Validate at scale.
Ship accessible websites, faster.