HTML Guides for standard
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.
This error is not an HTML validation issue — it is a network connectivity problem between your browser (or the W3C validator tool) and the server it is trying to reach.
The W3C Markup Validation Service at https://validator.w3.org needs to fetch your webpage over HTTP to check it. A SocketTimeoutException: Connect Timeout means the validator's server could not establish a connection to your URL within its time limit. Common causes include:
- The target server is down or unreachable from the validator's network.
- A firewall or security group blocks incoming requests from external servers.
- The server is behind a VPN, on
localhost, or on a private network that the validator cannot access. - DNS resolution fails for the provided URL.
- The server takes too long to respond, exceeding the validator's timeout threshold.
How to work around it
If the validator cannot reach your site, validate the HTML directly instead of providing a URL. Copy your HTML source and paste it into the "Validate by Direct Input" tab on https://validator.w3.org/#validate_by_input. You can also use the "Validate by File Upload" option to upload an .html file from your machine.
For local development, the Nu Html Checker can run locally as a standalone Java application or Docker container, which removes the need for any external network access:
java-cpvnu.jarnu.validator.servlet.Main8888
This starts a local instance of the validator on port 8888, and you can validate pages hosted on localhost without timeout issues.
A resource linked in your HTML (such as a stylesheet, script, or image) returned a 500 Internal Server Error when the W3C validator tried to fetch it.
This is not an HTML syntax error — it's a server-side problem. The W3C validator attempts to retrieve external resources referenced in your document to perform additional checks. When it encounters a 500 status code, it means the remote server failed to process the request. This could be caused by a misconfigured server, a broken backend script, a temporarily unavailable resource, or a URL that only works with specific headers (like cookies or authentication) that the validator doesn't send.
Common culprits include <link> elements pointing to CSS files, <script> elements loading JavaScript, or even resources referenced in <img> or <source> tags.
To fix this, verify that the URL is correct and publicly accessible. Open it directly in your browser or test it with a tool like curl. If the resource is on your own server, check your server logs for the cause of the 500 error. If it's a third-party resource, consider hosting a local copy or using a CDN alternative.
HTML Examples
Before — referencing an unreachable resource
<linkrel="stylesheet"href="https://example.com/broken-endpoint/styles.css">
<scriptsrc="https://example.com/broken-endpoint/app.js"></script>
After — using a valid, accessible URL
<linkrel="stylesheet"href="https://example.com/css/styles.css">
<scriptsrc="https://example.com/js/app.js"></script>
If the resource is temporarily down and outside your control, the validator warning will resolve itself once the remote server is fixed. You can safely treat this as a warning rather than a blocking error in that case.
A remote resource referenced in your HTML returned an HTTP 508 (Loop Detected) status, meaning the server encountered an infinite loop while trying to serve the file.
This error occurs when your HTML references an external resource — such as a stylesheet, script, image, or other linked file — and the server hosting that resource gets stuck in a redirect loop or circular dependency. The W3C validator tried to fetch the resource but couldn't because the remote server gave up.
This is a server-side issue, not an HTML syntax error. The problem lies with the server hosting the resource, not your markup. Common causes include misconfigured redirects, circular symbolic links on the server, or WebDAV configurations that detect infinite loops.
To fix this, you should:
- Check the URL — Open the referenced URL directly in a browser to confirm it fails.
- Fix the server configuration — If you control the server, look for circular redirects or recursive includes.
- Host the resource yourself — If you don't control the remote server, download the resource and serve it locally.
- Use a different CDN or source — Switch to a reliable alternative host.
HTML Examples
Before: referencing an unreachable remote resource
<linkrel="stylesheet"href="https://example.com/looping/styles.css">
<scriptsrc="https://example.com/looping/app.js"></script>
After: hosting locally or using a reliable CDN
<linkrel="stylesheet"href="/css/styles.css">
<scriptsrc="/js/app.js"></script>
If the resource is a popular library, use a trusted CDN instead:
<linkrel="stylesheet"href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css">
A < character appearing where an attribute name is expected typically means a closing > is missing on the previous tag, causing the browser to interpret the next tag as an attribute.
This error occurs when you forget to close an HTML element's opening tag with >. The validator sees the < of the next element and thinks it's still parsing attributes of the previous element. It's a common typo that can cascade into multiple confusing errors.
For example, if you write <div without the closing >, the following <p> tag gets parsed as if it were an attribute of the div, triggering this error.
HTML Examples
❌ Incorrect
<divclass="container"
<p>Hello, world!</p>
</div>
The <div> tag is missing its closing > after "container", so the validator sees <p> as part of the div's attribute list.
✅ Correct
<divclass="container">
<p>Hello, world!</p>
</div>
Make sure every opening tag is properly closed with >. If the error points to a specific line, check the tag immediately before that line for a missing >.
The < and > characters have special meaning in HTML — they signal the start and end of tags. When the parser encounters </>, it sees what looks like a closing tag with no element name, which is invalid in HTML. This sequence can appear in your markup for two main reasons:
- Unescaped text content: You're trying to display the literal characters
</>as visible text on the page (common in tutorials, documentation, or code snippets), but the browser interprets them as markup rather than content. - Mistyped end tag: You intended to write a proper closing tag like
</p>or</div>but accidentally omitted the element name, leaving just</>.
This matters because browsers may silently discard the malformed tag or interpret it in unexpected ways, leading to broken layouts or missing content. Screen readers and other assistive technologies may also struggle with the resulting DOM structure. Properly escaping special characters and writing well-formed tags ensures consistent rendering across all browsers and devices.
To fix this, determine which scenario applies. If you want to display the literal text </>, replace < with < and > with >. If you meant to close an element, add the correct element name between </ and >.
Examples
Unescaped angle brackets in text content
This triggers the error because the parser sees </> as an invalid closing tag:
<!-- ❌ Bad: raw </> in text content -->
<p>In JSX, self-closing tags use the </> syntax.</p>
Escape the angle brackets using HTML character entities:
<!-- ✅ Good: properly escaped characters -->
<p>In JSX, self-closing tags use the </> syntax.</p>
Mistyped closing tag with missing element name
This triggers the error because the closing tag has no name:
<!-- ❌ Bad: empty closing tag -->
<divclass="container">
<p>Some content here.</p>
</>
Add the correct element name to the closing tag:
<!-- ✅ Good: proper closing tag -->
<divclass="container">
<p>Some content here.</p>
</div>
Displaying code snippets with angle brackets
When writing about HTML or XML in your page content, all angle brackets in text must be escaped:
<!-- ❌ Bad: unescaped tags in text -->
<p>Use <strong> to make text bold and </strong> to close it.</p>
<!-- ✅ Good: escaped tags in text -->
<p>Use <strong> to make text bold and </strong> to close it.</p>
Using the <code> element for inline code
Even inside <code> elements, angle brackets must still be escaped — the <code> element only changes visual presentation, it does not prevent HTML parsing:
<!-- ❌ Bad: unescaped inside <code> -->
<p>A React fragment looks like <code><></code> and <code></></code>.</p>
<!-- ✅ Good: escaped inside <code> -->
<p>A React fragment looks like <code><></code> and <code></></code>.</p>
Using <pre> blocks for larger code examples
The same escaping rules apply within <pre> elements:
<!-- ✅ Good: escaped characters inside pre -->
<pre><code><div>
<p>Hello, world!</p>
</div></code></pre>
If you frequently need to display code and find manual escaping tedious, consider using a JavaScript-based syntax highlighting library that handles escaping automatically, or use a build tool or templating engine that escapes HTML entities for you.
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
Pro Trial
Full Pro access. Cancel anytime.
Start Pro Trial →Join teams across 40+ countries