HTML Validation

HTML Guides for html

Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.

Scan Your Site Free

Attribute “isolang” not allowed on element “html” at this point.

The W3C HTML Validator reports this error when it encounters isolang on the <html> element because isolang is not a recognized attribute in any version of HTML. This typically happens when developers attempt to specify the document’s language but use an incorrect or made-up attribute name, possibly confusing it with ISO language code terminology.

The correct attribute for declaring a document’s language is lang. This attribute accepts a valid BCP 47 language tag, which in most cases is a simple two-letter ISO 639-1 code (like en for English, fr for French, or pt for Portuguese). You can also use extended subtags for regional variants, such as en-US for American English or pt-BR for Brazilian Portuguese.

Setting the lang attribute properly is important for several reasons:

Accessibility: Screen readers use the lang attribute to select the correct pronunciation rules, ensuring content is read aloud accurately.
SEO: Search engines use the language declaration to serve the right content to users based on their language preferences.
Browser behavior: Browsers rely on lang for features like spell-checking, hyphenation, and selecting appropriate default fonts for the given language.
Standards compliance: Only recognized attributes pass W3C validation, and valid markup ensures consistent, predictable behavior across browsers.

To fix this issue, simply replace isolang with lang on your <html> element. Keep the same language code value—it’s the attribute name that’s wrong, not the value.

Examples

❌ Incorrect: Using the invalid isolang attribute

<!DOCTYPE html>
<html isolang="pt">
  <head>
    <title>Minha Página</title>
  </head>
  <body>
    <p>Olá, mundo!</p>
  </body>
</html>

This triggers the error: Attribute “isolang” not allowed on element “html” at this point.

✅ Correct: Using the lang attribute

<!DOCTYPE html>
<html lang="pt">
  <head>
    <title>Minha Página</title>
  </head>
  <body>
    <p>Olá, mundo!</p>
  </body>
</html>

✅ Correct: Using a regional language subtag

<!DOCTYPE html>
<html lang="pt-BR">
  <head>
    <title>Minha Página</title>
  </head>
  <body>
    <p>Olá, mundo!</p>
  </body>
</html>

Common language codes

Here are some frequently used ISO 639-1 language codes for the lang attribute:

en — English
es — Spanish
fr — French
de — German
pt — Portuguese
zh — Chinese
ja — Japanese
ar — Arabic
ko — Korean
ru — Russian

Bad value X for attribute “multiple” on element “input”.

Invalid value used for the multiple attribute on an input element.

The multiple attribute is a boolean attribute for certain input types (e.g., email, file). Boolean attributes must appear without a value (or with the same name as value in legacy cases), and they only work on specific types. Valid usage: <input type="email" multiple> or <input type="file" multiple>. Invalid usage includes multiple="1", multiple="true", or using multiple on unsupported types like text or number. The email type allows comma-separated addresses when multiple is present; the file type allows selecting more than one file.

HTML Examples

Example that reproduces the error

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Invalid multiple</title>
</head>
<body>
<!-- Invalid: value on boolean attribute, and wrong type -->

  <input type="text" name="tags" multiple="1">
</body>
</html>

Corrected example

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Valid multiple</title>
</head>
<body>
<!-- Valid: boolean attribute without a value on supported types -->

  <input type="email" name="recipients" multiple placeholder="name@example.com, other@example.com">

  <input type="file" name="attachments" multiple>
</body>
</html>

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

<!-- Content may be empty or incomplete -->

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.1 200 OK
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Page</title>
  </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) => {
  const html = 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 -I https://example.com/page

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

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

html
403

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)

<img src="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

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

Broken stylesheet reference (triggers the error)

<link rel="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

<link rel="stylesheet" href="/css/styles.css">

Broken script reference with incorrect path (triggers the error)

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

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

Fixed script reference

<script src="/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:

<img src="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

<img src="/images/logo.png" alt="Company logo">

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

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

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

<link rel="stylesheet" href="https://example.com/styles/main.css">
<script src="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

<link rel="stylesheet" href="/css/main.css">
<script src="/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

<script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"></script>
<script>
  if (typeof jQuery === "undefined") {
    var s = 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.

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

doctype
html

The <!DOCTYPE html public "-//W3C//DTD HTML 4.0 Transitional//EN"> doctype triggers quirks mode in modern browsers and is not compliant with HTML5 standards.

The HTML5 specification requires the use of a simple doctype declaration, which ensures standards mode rendering. The correct doctype is <!DOCTYPE html>, which must appear at the very top of every HTML5 document. Legacy doctypes like HTML 4.0 Transitional are obsolete for modern web development and can cause inconsistent browser behavior.

Example of correct usage:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Valid HTML5 Doctype Example</title>
  </head>
  <body>
    <p>Your content here.</p>
  </body>
</html>

Replace any legacy or malformed doctype with the above declaration to conform to current HTML standards.

Stray start tag “html”.

The <html> element serves as the root of an HTML document. According to the HTML specification, there can only be one root element, and it must contain exactly one <head> element followed by one <body> element. When the browser’s parser encounters a second <html> start tag, it doesn’t know what to do with it — the tag is considered “stray” because it appears in a context where it is not expected or allowed.

This error typically occurs in a few common scenarios:

Copy-paste mistakes — When copying HTML from another file, you may accidentally paste an entire document (including its <html> tag) inside an existing document.
Template or include errors — Server-side includes, template engines, or component-based frameworks may inject a full HTML document structure (with its own <html> tag) into a page that already has one.
Merging files incorrectly — Combining multiple HTML files without removing the structural tags from the inner files.
Accidental duplication — Simply having a duplicate <html> tag due to a typo or editing oversight.

A stray <html> tag signals a malformed document structure. Browsers will attempt to recover by ignoring the duplicate tag, but the intent behind the markup becomes ambiguous. This can lead to unpredictable rendering, broken styles, or scripts that fail to target elements correctly. It also harms accessibility, as screen readers and other assistive technologies rely on a well-formed document tree to interpret content.

To fix this issue, search your HTML source for all instances of <html and ensure only one exists — at the very top of the document, right after the <!DOCTYPE html> declaration. If you find a second one, remove it along with any corresponding duplicate </html>, <head>, </head>, <body>, and </body> tags that came with it, keeping only the actual content you need.

Examples

Incorrect: Duplicate <html> tag from pasted content

This example shows a full HTML document accidentally embedded inside another, which produces the stray start tag error:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Welcome</h1>

<!-- Accidentally pasted another full document -->

    <!DOCTYPE html>
    <html lang="en">
      <head>
        <title>Other Page</title>
      </head>
      <body>
        <p>This content was pasted from another file.</p>
      </body>
    </html>

  </body>
</html>

Correct: Single <html> element with merged content

Remove the duplicate document structure and keep only the content you need:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <h1>Welcome</h1>

<!-- Only the relevant content from the other file -->

    <p>This content was pasted from another file.</p>
  </body>
</html>

Incorrect: Accidental duplicate <html> tag

Sometimes the duplication is a simple typo:

<!DOCTYPE html>
<html lang="en">
<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Correct: Single <html> tag

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

Checking template-based projects

If you use a templating system (e.g., PHP includes, Jinja2, Handlebars, or similar), make sure your partials and includes contain only content fragments — not full document structures. For example, an included partial should look like this:

<!-- partial: sidebar.html — no <html>, <head>, or <body> tags -->

<aside>
  <nav>
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
</aside>

The key rule is simple: every HTML document must have exactly one <html> element. If the validator reports a stray start tag, trace it back to its source — whether that’s a copy-paste error, a template include, or a simple duplication — and remove it.

The “version” attribute on the “html” element is obsolete. You can safely omit it.

In earlier versions of HTML, the version attribute on the <html> element served as a way to indicate the DTD (Document Type Definition) the document followed. For example, you might have seen something like <html version="-//W3C//DTD HTML 4.01//EN">. This was largely redundant even then, because the <!DOCTYPE> declaration at the top of the document already communicated the same information to browsers and validators.

With the introduction of HTML5, the version attribute was officially marked as obsolete. The HTML Living Standard maintained by WHATWG does not define or support it. Modern browsers completely ignore it, so it has no functional effect on rendering or behavior. However, keeping it in your markup produces a validation warning from the W3C HTML Validator and adds unnecessary clutter to your code.

Removing this attribute has no side effects. The <!DOCTYPE html> declaration is the only mechanism needed to signal that your document uses the current HTML standard. Keeping your markup clean and free of obsolete attributes improves maintainability and ensures your documents pass validation without unnecessary warnings.

How to fix it

Locate the <html> tag in your document.
Remove the version attribute and its value entirely.
Ensure you have a valid <!DOCTYPE html> declaration at the top of the document.
Keep the lang attribute on the <html> element, as it is important for accessibility and internationalization.

Examples

Incorrect: using the obsolete version attribute

<!DOCTYPE html>
<html version="-//W3C//DTD HTML 4.01//EN" lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

This triggers the W3C validator warning: The “version” attribute on the “html” element is obsolete.

Correct: version attribute removed

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>My Page</title>
  </head>
  <body>
    <p>Hello, world!</p>
  </body>
</html>

The version attribute has been removed, and the document remains fully valid. The <!DOCTYPE html> declaration and the lang attribute are the only things needed on the <html> element for a well-formed, standards-compliant document.

✓ HTML validation on every page

✓ Accessibility checks (WCAG / Axe)

✓ Scheduled automatic reports

✓ Up to 5,000 pages per report

From $19/month Compare plans →

Category: HTML Validation
Engine: W3C Validator
Total guides: 10

Browse by Tag

202 403 404 429 503 CSS ISO 639-1 a aria auto autocomplete bad value button charset css doctype encoding end tag heading height href html http-equiv id iframe img input isolang label lang link media meta multiple name nesting not allowed obsolete page not found property rate limit role script section select sizes src srcset start tag stray svg table td tel th too many requests type utf-8 version video width xmlns

Ready to validate your sites?
Start your free trial today.

Pro Trial Free Trial