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.
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
<link rel="stylesheet" href="https://example.com/broken-endpoint/styles.css">
<script src="https://example.com/broken-endpoint/app.js"></script>
After — using a valid, accessible URL
<link rel="stylesheet" href="https://example.com/css/styles.css">
<script src="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 < 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
<div class="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
<div class="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 -->
<div class="container">
<p>Some content here.</p>
</>
Add the correct element name to the closing tag:
<!-- ✅ Good: proper closing tag -->
<div class="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