HTML Guides
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.
The W3C HTML Validator raises this error when it encounters a namespaced attribute such as xmlns:m, xmlns:o, xmlns:v, or any other xmlns:* declaration in an HTML document. These prefixed namespace bindings are an XML concept defined in the XML Namespaces specification. In the HTML syntax (documents served with the text/html MIME type), the HTML parser does not treat these as namespace declarations — it treats them as regular attributes with a colon in the name. Because such attribute names are not serializable in XML 1.0, the validator reports the error.
This issue is extremely common with content exported from Microsoft Office (Word, Excel, PowerPoint). When you save or copy Office content as HTML, the generated markup often includes namespace declarations like xmlns:m (Office Math Markup Language), xmlns:o (Office namespace), xmlns:v (VML), and xmlns:w (Word-specific markup). These declarations were designed for older, XML-based HTML rendering and serve no purpose in modern HTML5 documents.
Why This Is a Problem
- Standards compliance: The HTML5 specification only permits the
xmlnsattribute (without a prefix) on the<html>element, and only with the valuehttp://www.w3.org/1999/xhtml. Prefixed forms likexmlns:mare not allowed. - Serialization: If a tool attempts to serialize the DOM as XML (for example,
XMLSerializer), attributes with colons that aren't properly bound namespaces can cause failures or unexpected output. - No functional benefit: In an HTML document, the browser's HTML parser ignores these namespace bindings. They don't enable any special behavior — they're dead weight in your markup.
- Maintainability: Leaving Office-generated namespace clutter in your HTML makes the code harder to read and maintain.
How to Fix It
- Remove the
xmlns:*attribute from your HTML element (or whichever element it appears on). In most cases, this is all you need to do — the namespaced content from Office isn't rendered by browsers anyway. - Clean up Office-generated HTML by stripping out all proprietary namespaces, conditional comments, and Office-specific elements. Tools like HTML Tidy or your editor's "paste as plain text" feature can help.
- Use native HTML5 equivalents where possible. HTML5 natively supports MathML and SVG without requiring explicit namespace declarations.
- Switch to XHTML only if you have a genuine need for XML namespaces. This means serving the document with the
application/xhtml+xmlMIME type and using well-formed XML syntax throughout.
Examples
Incorrect: Office-generated namespace declarations
This markup, typical of content exported from Microsoft Word, triggers the validation error:
<!DOCTYPE html>
<htmlxmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:v="urn:schemas-microsoft-com:vml">
<head>
<title>Office Export</title>
</head>
<body>
<p>Content from Word</p>
</body>
</html>
Correct: Clean HTML5 without namespace declarations
Remove all xmlns:* attributes and any associated Office-specific markup:
<!DOCTYPE html>
<htmllang="en">
<head>
<metacharset="utf-8">
<title>Office Export</title>
</head>
<body>
<p>Content from Word</p>
</body>
</html>
Incorrect: Single namespace on a non-html element
The error can also appear on other elements if a tool inserts namespace attributes:
<divxmlns:custom="http://example.com/ns">
<p>Some content</p>
</div>
Correct: Remove the namespace attribute
<div>
<p>Some content</p>
</div>
Using MathML natively in HTML5
If the xmlns:m attribute was added to support math content, note that HTML5 supports MathML directly without any namespace declaration:
<!DOCTYPE html>
<htmllang="en">
<head>
<metacharset="utf-8">
<title>MathML in HTML5</title>
</head>
<body>
<p>The quadratic formula:</p>
<math>
<mi>x</mi>
<mo>=</mo>
<mfrac>
<mrow>
<mo>-</mo>
<mi>b</mi>
<mo>±</mo>
<msqrt>
<msup><mi>b</mi><mn>2</mn></msup>
<mo>-</mo>
<mn>4</mn><mi>a</mi><mi>c</mi>
</msqrt>
</mrow>
<mrow>
<mn>2</mn><mi>a</mi>
</mrow>
</mfrac>
</math>
</body>
</html>
No xmlns:m attribute is needed — the browser recognizes <math> as MathML automatically.
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:oattribute from any element where it appears (typically the<html>tag). - Remove related Office namespace attributes such as
xmlns:v,xmlns:w,xmlns:x, andxmlns: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.
Custom namespace declarations like xmlns:rdf are not serializable as XML 1.0 when used inside HTML5 documents.
In HTML5 (the text/html serialization), the xmlns attribute is only supported in a very limited way. You can use xmlns to declare the default namespace on the <html> or <svg> element, but you cannot declare additional namespace prefixes like xmlns:rdf, xmlns:dc, or xmlns:cc. These prefixed namespace declarations are a feature of XML and XHTML, and the HTML5 parser simply treats them as regular attributes — which then fail XML 1.0 serialization rules.
This commonly happens when SVG files are exported from tools like Inkscape, which embed RDF metadata with namespace declarations. When you paste or include such SVGs directly in an HTML5 document, the validator flags these attributes.
The fix is straightforward: remove the unsupported namespace declarations and any elements that depend on them. If the SVG contains <rdf:RDF>, <cc:Work>, or <dc:title> blocks, those can be safely removed without affecting the visual rendering of the SVG.
HTML Examples
❌ Invalid: SVG with unsupported namespace declarations
<svgxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
viewBox="0 0 100 100">
<metadata>
<rdf:RDF>
<cc:Workrdf:about="">
<dc:title>My Icon</dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
✅ Valid: SVG with namespace declarations and metadata removed
<svgviewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
If you need to preserve metadata, consider adding it outside the SVG using standard HTML elements like <meta> tags or structured data formats such as JSON-LD.
When graphic design tools like Affinity Designer (formerly Serif) export SVG files, they often embed custom namespace declarations such as xmlns:serif="http://www.serif.com/". These namespaces allow the editor to store its own metadata — like layer names, grouping information, or application-specific settings — inside the SVG file. While this metadata is useful if you re-open the file in the original editor, it has no meaning in a web browser.
The HTML5 specification defines a specific set of namespace attributes that are allowed in SVG elements (such as xmlns, xmlns:xlink, and xmlns:xml). Any namespace prefix not in this predefined list — like xmlns:serif, xmlns:inkscape, or xmlns:sodipodi — triggers this validation error because the HTML parser cannot serialize these attributes back into well-formed XML 1.0. This isn't just a theoretical concern: non-serializable attributes can cause issues when the DOM is manipulated via JavaScript or when the markup is processed by XML-based tools.
Beyond the xmlns:serif declaration itself, you'll likely find attributes in the SVG that use this namespace prefix, such as serif:id="layer1". These should also be removed since they reference a namespace the browser doesn't understand.
How to Fix It
- Remove the
xmlns:serifattribute from the<svg>element. - Remove any attributes prefixed with
serif:(e.g.,serif:id) from child elements within the SVG. - If you re-export the SVG, check your editor's export settings — some tools offer a "clean" or "optimized" export option that strips proprietary metadata.
- Consider using an SVG optimization tool like SVGO to automatically clean up unnecessary attributes.
Examples
❌ Invalid: SVG with xmlns:serif attribute
<svgxmlns="http://www.w3.org/2000/svg"
xmlns:serif="http://www.serif.com/"
viewBox="0 0 100 100"
width="100"
height="100">
<gserif:id="Layer 1">
<circlecx="50"cy="50"r="40"fill="blue"/>
</g>
</svg>
This triggers the error because xmlns:serif is not a recognized namespace in HTML5, and serif:id references that unsupported namespace.
✅ Valid: SVG with proprietary attributes removed
<svgxmlns="http://www.w3.org/2000/svg"
viewBox="0 0 100 100"
width="100"
height="100">
<g>
<circlecx="50"cy="50"r="40"fill="blue"/>
</g>
</svg>
Both xmlns:serif and serif:id have been removed. The SVG renders identically in the browser since those attributes were only meaningful to the editing application.
Handling Multiple Proprietary Namespaces
Exported SVGs sometimes contain several non-standard namespaces at once. Remove all of them:
<!-- ❌ Invalid: multiple proprietary namespaces -->
<svgxmlns="http://www.w3.org/2000/svg"
xmlns:serif="http://www.serif.com/"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
viewBox="0 0 200 200">
<rectx="10"y="10"width="180"height="180"fill="red"
serif:id="background"
inkscape:label="bg-rect"/>
</svg>
<!-- ✅ Valid: all proprietary namespaces and prefixed attributes removed -->
<svgxmlns="http://www.w3.org/2000/svg"
viewBox="0 0 200 200">
<rectx="10"y="10"width="180"height="180"fill="red"/>
</svg>
If you frequently work with SVGs from design tools, integrating an SVG optimizer into your build process can save time and ensure these non-standard attributes never reach production.
The xmlns:sodipodi attribute is a namespace declaration left over from the Inkscape SVG editor and is not valid in HTML5 documents.
When you embed an SVG directly in HTML, the HTML5 parser only recognizes a limited set of namespace declarations. The xmlns:sodipodi namespace (along with others like xmlns:inkscape) is specific to Inkscape's internal SVG format and serves no purpose in the browser. The W3C validator flags it because it cannot be serialized as XML 1.0 within the HTML5 context.
Inkscape adds several custom namespaces and attributes to SVG files for its own editing purposes. These include sodipodi:* and inkscape:* namespaces, along with their associated attributes and elements. Browsers simply ignore them, so removing them has no effect on how the SVG renders.
The fix is straightforward: remove the xmlns:sodipodi declaration from the <svg> tag, and also remove any sodipodi:* attributes or <sodipodi:*> elements throughout the SVG.
HTML Examples
❌ Invalid: SVG with Inkscape namespaces
<svgxmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
viewBox="0 0 100 100"
sodipodi:docname="icon.svg">
<sodipodi:namedviewpagecolor="#ffffff"/>
<circlecx="50"cy="50"r="40"fill="blue"
inkscape:label="Main Circle"/>
</svg>
✅ Valid: Cleaned SVG without editor-specific namespaces
<svgviewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
If you frequently export SVGs from Inkscape, consider using the "Plain SVG" export option (File → Save As → Plain SVG) instead of the default "Inkscape SVG" format. You can also use tools like SVGO or SVG Cleaner to automatically strip editor metadata before embedding.
The xmlns attribute defines the XML namespace for an element. For SVG, the correct namespace is http://www.w3.org/2000/svg, declared with xmlns="http://www.w3.org/2000/svg". The xmlns:svg attribute attempts to declare an additional prefixed namespace binding — essentially mapping the prefix svg: to the same namespace URI. This is redundant because the default (unprefixed) namespace already covers all SVG elements.
In HTML5, the parser handles namespaces internally. The HTML specification only permits a small set of namespace attributes: xmlns on certain elements (like <svg> and <math>) and xmlns:xlink for legacy compatibility. Arbitrary prefixed namespace declarations like xmlns:svg are not part of the HTML serialization format. The W3C validator raises this error because attributes containing colons in their local names (other than the specifically allowed ones) cannot be round-tripped through the HTML parser and serializer — they are "not serializable as XML 1.0."
Why this matters
- Standards compliance: HTML5 has strict rules about which namespace declarations are permitted. Using
xmlns:svgviolates these rules. - Serialization issues: If a browser parses the HTML and then re-serializes it (e.g., via
innerHTML), thexmlns:svgattribute may be lost, altered, or cause unexpected behavior because it falls outside the serializable attribute set. - Redundancy: Even in pure XML/SVG documents, declaring
xmlns:svg="http://www.w3.org/2000/svg"alongsidexmlns="http://www.w3.org/2000/svg"is unnecessary. The default namespace already applies to the<svg>element and all its unprefixed descendants.
How to fix it
- Locate the
<svg>element (or any element) that contains thexmlns:svgattribute. - Remove
xmlns:svg="http://www.w3.org/2000/svg"entirely. - Ensure the standard
xmlns="http://www.w3.org/2000/svg"attribute remains if needed (note that when embedding SVG inline in an HTML5 document, evenxmlnsis optional since the HTML parser infers the namespace automatically).
Examples
Incorrect: redundant prefixed namespace declaration
<svgxmlns="http://www.w3.org/2000/svg"xmlns:svg="http://www.w3.org/2000/svg"viewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
The xmlns:svg attribute triggers the validation error because it is not serializable in HTML.
Correct: standard namespace only
<svgxmlns="http://www.w3.org/2000/svg"viewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Correct: inline SVG in HTML5 without any namespace attribute
When SVG is embedded directly in an HTML5 document, the HTML parser automatically assigns the correct namespace, so you can omit xmlns altogether:
<svgviewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
This is perfectly valid and is the most common pattern for inline SVG in modern HTML. The xmlns attribute is only strictly necessary when the SVG is served as a standalone XML file (with a .svg extension or an image/svg+xml content type).
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:vattribute from your<html>element (or wherever it appears). - Remove any other legacy Microsoft namespace declarations such as
xmlns:o,xmlns:w, orxmlns: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.
HTML5 uses a specific serialization format that is distinct from XML. While XML allows you to declare arbitrary namespace prefixes using xmlns:prefix attributes, the HTML parser does not recognize or process these declarations. The HTML specification only supports a small set of predefined namespaces — the default HTML namespace, SVG (http://www.w3.org/2000/svg), MathML (http://www.w3.org/1998/Math/MathML), XLink, XML, and XMLNS — and these are handled implicitly through the appropriate embedding elements (<svg>, <math>), not through explicit xmlns: declarations.
The phrase "not serializable as XML 1.0" in the validator message means that this attribute cannot be round-tripped between the HTML parser and an XML serializer. The HTML parser treats xmlns:w as an opaque attribute name containing a colon, rather than as a namespace declaration. If you were to serialize this DOM back to XML, the result would be invalid because xmlns:w would be interpreted as a namespace declaration for a prefix that may conflict with actual element usage.
This issue almost always originates from content exported or pasted from Microsoft Word, Excel, or other Office applications. These tools generate markup laden with proprietary namespace declarations like xmlns:w, xmlns:o (Office), xmlns:v (VML), and xmlns:x (Excel). Along with these declarations come Office-specific elements and attributes (e.g., <w:WordDocument>, <o:OfficeDocumentSettings>) that have no meaning in a web browser and bloat your HTML.
Beyond being a validation error, leaving this markup in place creates several problems. It adds significant unnecessary weight to your pages, makes the source code harder to read and maintain, and signals that the HTML was auto-generated without cleanup — which can affect long-term maintainability. Browsers silently ignore these attributes and elements, so they provide no functional benefit.
How to fix it
- Remove all
xmlns:prefixed attributes from your HTML elements, includingxmlns:w,xmlns:o,xmlns:v,xmlns:x, and any others. - Remove any Office-specific elements that use those namespace prefixes, such as
<o:p>,<w:WordDocument>, or<v:shapetype>. These elements are meaningless in HTML5. - Clean up associated conditional comments like
<!--[if gte mso 9]>that often wrap Office-specific blocks. - Consider using a paste-cleanup tool if you regularly paste content from Word into your HTML. Many CMS platforms and text editors offer "paste as plain text" or "clean HTML" options.
If you genuinely need to work with Office Open XML namespaces, use an appropriate XML-based format (XHTML served as application/xhtml+xml, or OOXML documents) rather than standard HTML5.
Examples
Incorrect — Office namespace declarations in HTML
This markup is typical of content saved or exported from Microsoft Word:
<htmlxmlns:w="urn:schemas-microsoft-com:office:word"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:v="urn:schemas-microsoft-com:vml">
<head>
<title>Report</title>
<!--[if gte mso 9]> <w:WordDocument> <w:View>Normal</w:View> </w:WordDocument> <![endif]-->
<w:WordDocument>
<w:View>Normal</w:View>
</w:WordDocument>
<![endif]-->
</head>
<body>
<pclass="MsoNormal">Hello world<o:p></o:p></p>
</body>
</html>
Correct — Clean HTML without Office markup
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Report</title>
</head>
<body>
<p>Hello world</p>
</body>
</html>
Incorrect — Single namespace on the <html> element
Even a single custom namespace declaration triggers the error:
<htmlxmlns:w="urn:schemas-microsoft-com:office:word">
<head>
<title>My Page</title>
</head>
<body>
<p>Content here.</p>
</body>
</html>
Correct — Remove the attribute entirely
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My Page</title>
</head>
<body>
<p>Content here.</p>
</body>
</html>
Note that the default xmlns="http://www.w3.org/1999/xhtml" attribute on the <html> element is permitted (though unnecessary in HTML5), but any prefixed namespace declaration like xmlns:w is not.
When the W3C HTML Validator reports that an attribute is "not serializable as XML 1.0," it means the attribute name contains characters that fall outside the allowed range defined by the XML 1.0 specification. HTML5 documents can be serialized as either HTML or XML (XHTML), and the validator checks that your markup is compatible with both serialization formats. Attribute names in XML 1.0 must start with a letter or underscore and can only contain letters, digits, hyphens, underscores, periods, and certain Unicode characters — they cannot include characters like {, }, @, $, or other symbols commonly found in templating languages.
This issue most frequently appears when a server-side or client-side templating engine (such as Mustache, Handlebars, Angular, Jinja2, or Blade) fails to fully process its expressions before the HTML reaches the browser. Instead of the template placeholder being replaced with a proper value, the raw template syntax ends up in the HTML as a malformed attribute. For example, {{class}} might appear as an attribute name rather than being resolved to its intended value.
Why this matters
- Standards compliance: HTML that isn't serializable as XML 1.0 cannot be reliably converted to XHTML, which limits interoperability.
- Browser inconsistency: Browsers may handle invalid attribute names unpredictably, potentially ignoring the attribute entirely or misinterpreting surrounding markup.
- Accessibility: Malformed attributes can break ARIA attributes or other accessibility-related markup, making content inaccessible to assistive technologies.
- Tooling and parsing: XML-based tools, RSS feeds, and content syndication systems that consume your HTML will choke on attributes that violate XML naming rules.
How to fix it
- Check for unresolved template expressions. Inspect the rendered HTML (not your source templates) for leftover placeholders like
{{...}},<%= ... %>,@{...}, or similar patterns. - Ensure proper server-side rendering. Make sure your templating engine is correctly processing all expressions before the HTML is sent to the client.
- Remove invalid characters from attribute names. If you're using custom attributes, stick to valid
data-*attributes with names consisting only of lowercase letters, digits, and hyphens (after thedata-prefix). - Check for typos. A missing
=sign, quote, or space can cause a value to be interpreted as an attribute name.
Examples
Unresolved template placeholder in an attribute
This occurs when a template expression isn't processed and appears literally in the output:
<!-- ❌ Bad: template syntax rendered as attribute name -->
<div{{classBinding}}id="main">
<p>Hello, world!</p>
</div>
The fix is to ensure the template engine resolves the expression. The rendered output should look like this:
<!-- ✅ Good: attribute properly resolved -->
<divclass="container"id="main">
<p>Hello, world!</p>
</div>
Typo causing a value to be parsed as an attribute name
A missing equals sign or quotation mark can cause part of a value to become an attribute name with invalid characters:
<!-- ❌ Bad: missing = sign causes "bold}" to be treated as an attribute -->
<pstyle"font-weight:bold}" class="intro">Welcome</p>
<!-- ✅ Good: proper attribute syntax -->
<pstyle="font-weight:bold"class="intro">Welcome</p>
Special characters in custom attribute names
Using invalid characters directly in attribute names will trigger this error:
<!-- ❌ Bad: @ and $ are not valid in attribute names -->
<input@change="update"$value="test">
If you need custom attributes, use the standard data-* pattern:
<!-- ✅ Good: valid data attributes -->
<inputdata-change="update"data-value="test">
Angular-style bindings in static HTML
Frameworks like Angular use special attribute syntax (e.g., [property] or (event)) that is only valid within the framework's context and will fail validation if rendered directly:
<!-- ❌ Bad: framework-specific syntax in raw HTML -->
<img[src]="imageUrl"(load)="onLoad()">
If you're generating static HTML, use standard attributes instead:
<!-- ✅ Good: standard HTML attribute -->
<imgsrc="photo.jpg"alt="A photo">
Every HTML element has a defined set of attributes it accepts. The HTML specification maintains strict rules about which attributes belong on which elements. For example, the href attribute is valid on an <a> element but not on a <div>. The for attribute belongs on <label> and <output> elements but not on <span>. When you place an attribute on an element that doesn't recognize it, the validator flags the error.
This issue matters for several reasons. First, browsers may silently ignore unrecognized attributes, meaning your code might appear to work but isn't actually doing anything — leading to hard-to-diagnose bugs. Second, assistive technologies like screen readers rely on valid HTML to correctly interpret page structure and behavior. Invalid attributes can confuse these tools and degrade accessibility. Third, standards-compliant HTML ensures consistent behavior across all browsers and future-proofs your code.
There are several common causes of this error:
- Typos or misspellings — Writing
hieghtinstead ofheight, orscrinstead ofsrc. - Attributes on the wrong element — Using
placeholderon a<div>instead of an<input>or<textarea>. - Obsolete attributes — Using presentational attributes like
align,bgcolor, orborderthat have been removed from the HTML specification in favor of CSS. - Framework-specific attributes — Using attributes like
ng-click(Angular),v-if(Vue), or@click(Vue shorthand) that aren't part of standard HTML. These frameworks typically process them before the browser sees them, but the raw HTML won't validate. - Custom attributes without the
data-*prefix — Inventing your own attributes liketooltiporstatuswithout following thedata-*convention. - ARIA attributes with typos — Writing
aria-roleinstead of the correctrole, oraria-labelledinstead ofaria-labelledby.
Examples
Attribute used on the wrong element
The placeholder attribute is only valid on <input> and <textarea> elements:
<!-- ❌ "placeholder" not allowed on "div" -->
<divplaceholder="Enter text here">Content</div>
<!-- ✅ Use placeholder on a supported element -->
<inputtype="text"placeholder="Enter text here">
Obsolete presentational attribute
The align attribute has been removed from most elements in HTML5. Use CSS instead:
<!-- ❌ "align" not allowed on "div" -->
<divalign="center">Centered content</div>
<!-- ✅ Use CSS for presentation -->
<divstyle="text-align: center;">Centered content</div>
Custom attribute without data-* prefix
If you need to store custom data on an element, use the data-* attribute format:
<!-- ❌ "tooltip" not allowed on "span" -->
<spantooltip="More information">Hover me</span>
<!-- ✅ Use a data-* attribute for custom data -->
<spandata-tooltip="More information">Hover me</span>
The data-* attributes are specifically designed for embedding custom data. You can access them in JavaScript via the dataset property, e.g., element.dataset.tooltip.
Misspelled attribute
A simple typo can trigger this error:
<!-- ❌ "widht" not allowed on "img" -->
<imgsrc="photo.jpg"widht="300"alt="A photo">
<!-- ✅ Correct the spelling -->
<imgsrc="photo.jpg"width="300"alt="A photo">
ARIA attribute typo
ARIA attributes must match their exact specification names:
<!-- ❌ "aria-labelled" not allowed on "input" -->
<inputtype="text"aria-labelled="name-label">
<!-- ✅ Use the correct ARIA attribute name -->
<inputtype="text"aria-labelledby="name-label">
Framework-specific attributes
If you're using a JavaScript framework and want your source templates to validate, be aware that framework-specific syntax won't pass validation. In Vue, for example, you can use the data-* equivalent or accept that templates are preprocessed:
<!-- ❌ "v-if" not allowed on "div" -->
<divv-if="isVisible">Hello</div>
<!-- This is expected with Vue templates and is typically not a concern, since the framework processes these before they reach the browser. -->
since the framework processes these before they reach the browser. -->
When encountering this error, check the MDN Web Docs reference for the element in question to see which attributes it actually supports. This will quickly clarify whether you need to fix a typo, move the attribute to a different element, replace it with CSS, or convert it to a data-* attribute.
Custom XML namespace declarations like xmlns:dc are not allowed on <svg> elements in HTML5 documents.
In HTML5 (as opposed to XHTML), the parser only recognizes a limited set of namespace attributes on SVG elements: xmlns and xmlns:xlink. Any other namespace declarations, such as xmlns:dc, xmlns:cc, xmlns:rdf, or xmlns:svg, are invalid. These namespaces are commonly added by SVG editors like Inkscape but serve no purpose in an HTML5 context.
The SVG metadata that relies on these namespaces (like Dublin Core dc: elements or Creative Commons cc: elements) is also typically unnecessary when embedding SVGs in HTML. You can safely remove these namespace declarations and their associated metadata elements without affecting how the SVG renders.
Invalid Example
<svgxmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 100 100"
width="100"
height="100">
<metadata>
<rdf:RDF>
<cc:Workrdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:title>My Icon</dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Valid Example
<svgxmlns="http://www.w3.org/2000/svg"
viewBox="0 0 100 100"
width="100"
height="100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Remove all non-standard xmlns: attributes and the <metadata> block they support. If you're exporting from a tool like Inkscape, look for a "plain SVG" or "optimized SVG" export option, or use a tool like SVGO to clean up the output automatically.
The xmlns:dt attribute — short for "XML Namespace: datatypes" — was historically used in Microsoft-specific XML vocabularies (notably urn:schemas-microsoft-com:datatypes) to declare data type information on elements. It was common in older ASP and IE-era markup. However, HTML5 is not an XML language, and it does not support arbitrary XML namespace declarations on elements.
In HTML5, the only xmlns attribute permitted is xmlns="http://www.w3.org/1999/xhtml" on the <html> element itself, and even that exists solely for compatibility with XHTML serialization. Namespace-prefixed attributes like xmlns:dt, xmlns:o, or xmlns:v are invalid. The HTML parser simply does not recognize them, and the W3C validator will flag them with the error "Attribute 'xmlns:dt' not allowed here."
Why This Is a Problem
- Standards compliance: Using non-standard attributes means your document does not conform to the HTML specification, which can lead to unpredictable behavior across browsers.
- Legacy lock-in: The
xmlns:dtattribute is tied to Microsoft's proprietary data type schema. Modern browsers do not interpret or use this namespace, so it serves no functional purpose in an HTML5 document. - Validation noise: Invalid attributes generate validator errors that can obscure real issues in your markup, making it harder to catch genuine bugs.
- Accessibility and tooling: Screen readers, search engine crawlers, and other automated tools expect valid HTML. Non-standard attributes can confuse parsers or be silently discarded.
How to Fix It
- Remove the attribute. If
xmlns:dtwas carried over from legacy code or a CMS template and nothing in your application depends on it, simply delete it. - Replace with
data-*attributes. If you need to attach custom metadata to an element — for example, to indicate a data type for use by JavaScript — use an HTML5data-*attribute instead. - Use XHTML if XML namespaces are required. If you genuinely need XML namespace support (rare in modern web development), serve your document as
application/xhtml+xmlwith a proper XHTML doctype and XML declaration. Be aware this changes parsing rules significantly.
Examples
Incorrect: Using xmlns:dt in HTML5
This will trigger the validation error:
<ulxmlns:dt="urn:schemas-microsoft-com:datatypes">
<lidt:dt="string">Item one</li>
<lidt:dt="number">42</li>
</ul>
Both xmlns:dt on the <ul> and the dt:dt attributes on the <li> elements are invalid in HTML5.
Correct: Attribute removed
If the namespace declaration is unnecessary (which it almost always is in modern HTML), remove it along with any prefixed attributes:
<ul>
<li>Item one</li>
<li>42</li>
</ul>
Correct: Using data-* attributes for custom metadata
If your JavaScript or application logic needs to know the data type of each item, use valid data-* attributes:
<ul>
<lidata-type="string">Item one</li>
<lidata-type="number">42</li>
</ul>
You can then access these values in JavaScript with element.dataset.type.
Correct: Migrating a legacy div wrapper
A common legacy pattern places xmlns:dt on a container div:
<!-- Invalid -->
<divxmlns:dt="urn:schemas-microsoft-com:datatypes">
<spandt:dt="dateTime">2024-01-15</span>
</div>
The fixed version removes the namespace and uses standard attributes:
<div>
<timedatetime="2024-01-15">January 15, 2024</time>
</div>
In this case, the semantic <time> element with its datetime attribute is the proper HTML5 way to represent date and time values — no custom namespace needed.
Quick Checklist
- Search your codebase for
xmlns:dtand anydt:prefixed attributes. - Check CMS templates, server-generated markup, and copy-pasted legacy code — these are the most common sources.
- Remove the attributes or replace them with
data-*equivalents. - Re-validate your document to confirm the error is resolved.
The xmlns:fb attribute was an XML namespace declaration used to enable FBML (Facebook Markup Language) tags on websites. FBML allowed developers to embed Facebook-specific elements like <fb:like>, <fb:comments>, and <fb:share-button> directly in their HTML. Facebook officially retired FBML in 2011 and replaced it with the JavaScript SDK and social plugins, yet many websites still carry this outdated namespace declaration in their markup.
In HTML5, the only xmlns attribute allowed on the <html> element is the standard xmlns="http://www.w3.org/1999/xhtml", and even that is optional. Custom namespace prefixes like xmlns:fb or xmlns:og are XML constructs that have no meaning in HTML5 and are flagged as validation errors.
Why This Is a Problem
- Standards compliance: HTML5 does not support arbitrary XML namespace declarations. The
xmlns:fbattribute violates the HTML specification, producing a validation error. - Dead technology: FBML no longer functions. Facebook's servers no longer process FBML tags, so the namespace serves no purpose whatsoever.
- Code cleanliness: Keeping deprecated, non-functional attributes in your markup adds confusion for developers maintaining the codebase and suggests the site hasn't been updated in a long time.
How to Fix It
- Remove
xmlns:fb(and any other custom namespace likexmlns:og) from your<html>tag. - Remove any FBML tags such as
<fb:like>,<fb:comments>, or<fb:share-button>from your page content. - Replace with modern alternatives:
- Use the Facebook JavaScript SDK for social plugins.
- Use Open Graph
<meta>tags in the<head>to control how your pages appear when shared on Facebook. These<meta>tags use thepropertyattribute (e.g.,property="og:title") and do not require any namespace declaration in HTML5.
Examples
❌ Invalid: Using xmlns:fb on the <html> tag
<!DOCTYPE html>
<htmllang="en"xmlns:fb="http://ogp.me/ns/fb#">
<head>
<title>My Page</title>
</head>
<body>
<fb:likehref="https://example.com"width="300"></fb:like>
</body>
</html>
This triggers the error "Attribute 'xmlns:fb' not allowed here" because HTML5 does not permit custom XML namespace prefixes on the <html> element. The <fb:like> tag is also invalid HTML and no longer functional.
✅ Valid: Using Open Graph meta tags and the JavaScript SDK
<!DOCTYPE html>
<htmllang="en">
<head>
<metacharset="utf-8">
<title>My Page</title>
<metaproperty="og:title"content="My Page">
<metaproperty="og:description"content="A description of my page.">
<metaproperty="og:url"content="https://example.com">
<metaproperty="og:image"content="https://example.com/image.jpg">
</head>
<body>
<h1>My Page</h1>
<!-- Facebook Like button using the JavaScript SDK -->
<divclass="fb-like"data-href="https://example.com"data-width="300"data-layout="button_count"></div>
<scriptasyncdefercrossorigin="anonymous"
src="https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v18.0">
</script>
</body>
</html>
The xmlns:fb attribute is gone, Open Graph metadata is provided via standard <meta> tags, and the like button is rendered using Facebook's JavaScript SDK with data-* attributes—all fully valid HTML5.
The HTML5 specification strictly limits which attributes are valid on the <html> element—and on elements in general. Standard global attributes like lang, dir, class, and id are permitted, and in XHTML serialization the plain xmlns attribute is allowed to declare the default XHTML namespace. However, prefixed namespace declarations like xmlns:m, xmlns:o, xmlns:v, or xmlns:w are XML constructs that have no meaning in the HTML5 (text/html) parsing model.
These prefixed namespace attributes most often appear when content is generated by or copied from Microsoft Office products (Word, Excel, PowerPoint). Office uses custom XML namespaces such as xmlns:m for Office MathML (http://schemas.microsoft.com/office/2004/12/omml) and xmlns:o for Office-specific markup. When this markup is saved as HTML or pasted into a web page, these declarations come along and trigger validation errors.
Why This Is a Problem
- Standards compliance: The W3C HTML5 specification does not support custom XML namespace declarations in the
text/htmlserialization. Validators will flag every such attribute. - No functional benefit: HTML5 parsers ignore namespace prefixes entirely. The
xmlns:mdeclaration does nothing in a browser rendering an HTML5 page, so it is dead code. - Content bloat: Office-generated HTML often includes many unnecessary namespace declarations, inline styles, and proprietary elements that bloat the document and make it harder to maintain.
- Accessibility and interoperability: Clean, valid HTML is easier for assistive technologies, search engines, and other user agents to process reliably.
How to Fix It
- Remove the custom namespace attribute from the
<html>element (or whichever element it appears on). - Remove any elements or attributes that depend on that namespace prefix (e.g.,
<m:oMath>,<o:p>), since they are not valid HTML5 elements. - Replace with HTML5-native equivalents where possible. For example, MathML is natively supported in HTML5 without any namespace declaration—you can use
<math>elements directly. - If you truly need XML namespaces, serve your document as XHTML with the
application/xhtml+xmlcontent type instead oftext/html.
Examples
Incorrect: Custom namespace on the html element
This triggers the "Attribute xmlns:m not allowed here" error:
<!DOCTYPE html>
<htmlxmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
xmlns:o="urn:schemas-microsoft-com:office:office"
lang="en">
<head>
<title>Office Paste Example</title>
</head>
<body>
<p>Some content with Office markup.</p>
</body>
</html>
Correct: Clean HTML5 without namespace declarations
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Clean HTML5 Example</title>
</head>
<body>
<p>Some content without Office markup.</p>
</body>
</html>
Correct: Using MathML natively in HTML5
If the xmlns:m namespace was being used for mathematical content, HTML5 supports MathML directly without any namespace declaration:
<!DOCTYPE html>
<htmllang="en">
<head>
<title>MathML in HTML5</title>
</head>
<body>
<p>The quadratic formula:</p>
<math>
<mi>x</mi>
<mo>=</mo>
<mfrac>
<mrow>
<mo>-</mo>
<mi>b</mi>
<mo>±</mo>
<msqrt>
<mrow>
<msup><mi>b</mi><mn>2</mn></msup>
<mo>-</mo>
<mn>4</mn><mi>a</mi><mi>c</mi>
</mrow>
</msqrt>
</mrow>
<mrow>
<mn>2</mn><mi>a</mi>
</mrow>
</mfrac>
</math>
</body>
</html>
Incorrect: Namespace attribute on a non-html element
The same error can appear on other elements too:
<divxmlns:o="urn:schemas-microsoft-com:office:office">
<p>Office content</p>
</div>
Correct: Remove the namespace attribute
<div>
<p>Office content</p>
</div>
If you're cleaning up Office-generated HTML, consider using a dedicated tool or a "paste as plain text" option in your CMS to strip out proprietary markup before it enters your pages. This keeps your HTML lean, valid, and maintainable.
In XML and XHTML, the xmlns attribute is used to declare namespaces that allow elements and attributes from different vocabularies to coexist without naming conflicts. The xmlns:o prefix specifically declares the Microsoft Office namespace (urn:schemas-microsoft-com:office:office), which enables Office-specific elements and attributes like <o:p> (Office paragraph markers) within the document.
HTML5, however, is not an XML language. The HTML5 specification only permits the xmlns attribute on the <html> element (and only with the value http://www.w3.org/1999/xhtml), along with xmlns:xlink on SVG elements. Custom namespace prefixes like xmlns:o, xmlns:v (VML), and xmlns:w (Word) are not recognized as valid attributes on any HTML5 element and will trigger validation errors.
Why This Happens
This issue most commonly occurs when:
- Content is pasted from Microsoft Word into a WYSIWYG editor or CMS. Word generates its own flavor of HTML that includes Office namespace declarations and proprietary elements.
- HTML files are exported from Office applications like Word, Excel, or Outlook. These exports produce markup heavily reliant on Office-specific namespaces.
- Email templates are built using tools that generate Office-compatible HTML, carrying namespace baggage into standard web pages.
Why It Matters
- Standards compliance: HTML5 does not support arbitrary XML namespace declarations, so these attributes make your document invalid.
- Bloated markup: Office-generated HTML often includes not just the namespace declarations but also large amounts of Office-specific elements, conditional comments, and inline styles that increase page size significantly.
- Maintenance difficulty: Office-flavored HTML is harder to read, edit, and maintain compared to clean, standards-compliant markup.
- Potential rendering issues: While browsers generally ignore unrecognized attributes, the accompanying Office-specific elements (like
<o:p>) can occasionally cause unexpected spacing or layout behavior.
How to Fix It
- Remove all
xmlns:oattributes from your HTML elements. - Remove any Office-specific elements such as
<o:p>,<o:SmartTagType>, or similar tags that rely on the Office namespace. - Check for other Office namespaces like
xmlns:v,xmlns:w,xmlns:m, andxmlns:st1— these should also be removed. - Clean pasted content before inserting it into your HTML. Many text editors and CMS platforms offer a "Paste as plain text" option that strips out Office formatting.
- If you use a CMS or rich text editor, look for a "Clean up Word HTML" or similar feature to automatically strip Office artifacts.
Examples
❌ Invalid: Office namespace declarations on elements
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Company Report</title>
</head>
<bodyxmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:w="urn:schemas-microsoft-com:office:word">
<h1>Quarterly Report</h1>
<pclass="MsoNormal">Revenue increased by 15% this quarter.<o:p></o:p></p>
<pclass="MsoNormal">Expenses remained stable.<o:p></o:p></p>
</body>
</html>
This markup contains three Office namespace declarations on the <body> element and uses <o:p> elements inside paragraphs — all of which are invalid in HTML5.
✅ Valid: Clean HTML without Office namespaces
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Company Report</title>
</head>
<body>
<h1>Quarterly Report</h1>
<p>Revenue increased by 15% this quarter.</p>
<p>Expenses remained stable.</p>
</body>
</html>
❌ Invalid: Namespace on a div element
<divxmlns:o="urn:schemas-microsoft-com:office:office">
<pclass="MsoNormal">Meeting notes from Tuesday.<o:p></o:p></p>
</div>
✅ Valid: Clean version
<div>
<p>Meeting notes from Tuesday.</p>
</div>
Notice that in the corrected examples, the class="MsoNormal" attribute was also removed. While MsoNormal is technically a valid class name that won't cause a validation error, it's an Office-generated class with no purpose unless you have corresponding CSS rules — removing it keeps your markup clean.
If you genuinely need XML namespace support for document processing, use a proper XHTML document served with the application/xhtml+xml content type, or handle the XML processing separately from your web-facing HTML.
In older XHTML documents, XML namespaces were declared using the xmlns attribute with a prefix, such as xmlns:og="http://ogp.me/ns#". While this syntax was valid in XHTML, HTML5 does not support custom XML namespace declarations on the <html> element. The W3C validator will flag any xmlns:* prefixed attribute (like xmlns:og, xmlns:fb, etc.) as invalid because HTML5 has a strictly defined set of allowed attributes on the <html> element.
The Open Graph Protocol, originally developed by Facebook, allows web pages to become rich objects in a social graph. Major platforms like Facebook, Twitter, LinkedIn, and others rely on Open Graph <meta> tags to generate link previews. The official Open Graph Protocol specification recommends using the prefix attribute on the <html> element instead of the xmlns:og namespace declaration.
The prefix attribute is part of the RDFa specification and is recognized by HTML5 as a valid way to declare vocabulary prefixes. By switching to prefix="og: https://ogp.me/ns#", you maintain full Open Graph functionality while keeping your HTML valid.
How to fix it
- Locate the
<html>tag in your document. - Remove any
xmlns:og(or similarxmlns:*) attributes. - Add or update the
prefixattribute with the appropriate namespace declaration.
If you use multiple prefixes (e.g., Open Graph and Facebook-specific tags), you can combine them in a single prefix attribute, separated by a space.
Examples
❌ Invalid: Using xmlns:og (XHTML-style namespace)
<!DOCTYPE html>
<htmllang="en"xmlns:og="http://ogp.me/ns#">
<head>
<title>My Page</title>
<metaproperty="og:title"content="My Page Title"/>
<metaproperty="og:type"content="website"/>
<metaproperty="og:url"content="https://example.com/"/>
<metaproperty="og:image"content="https://example.com/image.jpg"/>
</head>
<body>
<p>Page content here.</p>
</body>
</html>
This triggers the validator error: Attribute "xmlns:og" not allowed here.
✅ Valid: Using the prefix attribute
<!DOCTYPE html>
<htmllang="en"prefix="og: https://ogp.me/ns#">
<head>
<title>My Page</title>
<metaproperty="og:title"content="My Page Title"/>
<metaproperty="og:type"content="website"/>
<metaproperty="og:url"content="https://example.com/"/>
<metaproperty="og:image"content="https://example.com/image.jpg"/>
</head>
<body>
<p>Page content here.</p>
</body>
</html>
✅ Valid: Multiple prefixes (Open Graph and Facebook)
If you also use Facebook-specific meta tags (like fb:app_id), declare both prefixes:
<!DOCTYPE html>
<htmllang="en"prefix="og: https://ogp.me/ns# fb: https://ogp.me/ns/fb#">
<head>
<title>The Rock (1996)</title>
<metaproperty="fb:app_id"content="123456789"/>
<metaproperty="og:title"content="The Rock"/>
<metaproperty="og:type"content="video.movie"/>
<metaproperty="og:url"content="https://www.imdb.com/title/tt0117500/"/>
<metaproperty="og:image"content="https://ia.media-imdb.com/images/rock.jpg"/>
</head>
<body>
<p>Page content here.</p>
</body>
</html>
❌ Invalid: Multiple xmlns declarations
This older pattern with multiple namespace declarations is equally invalid in HTML5:
<htmlxmlns:og="http://ogp.me/ns#"xmlns:fb="http://ogp.me/ns/fb#">
Replace it with the single prefix attribute as shown in the examples above.
In HTML5, the only namespace attributes recognized on SVG elements are xmlns (for the SVG namespace) and xmlns:xlink (for XLink, though xlink is now largely deprecated in favor of plain attributes). Any other custom namespace declarations — such as xmlns:serif, xmlns:inkscape, or xmlns:sketch — are not permitted by the HTML specification and will trigger a validation error.
Design tools like Affinity Designer, Adobe Illustrator, Inkscape, and Sketch often embed proprietary namespace declarations and metadata attributes in exported SVG files. These serve as internal markers for the design application (for example, to preserve layer names or editor-specific settings) but have no meaning in a web browser. Browsers simply ignore them, so they add unnecessary bytes to your page without providing any benefit.
Removing these attributes is important for several reasons:
- Standards compliance: The HTML5 parser has a fixed list of allowed namespace declarations. Custom ones violate the spec.
- Clean markup: Proprietary metadata bloats your SVG files with information that only matters inside the originating design tool.
- Maintainability: Removing tool-specific artifacts makes your SVGs easier to read, edit, and optimize.
To fix this, open your SVG file (or the HTML file containing inline SVGs) and remove the xmlns:serif attribute from the <svg> element. You should also search for and remove any attributes prefixed with serif: (such as serif:id) throughout the SVG, since those depend on the now-removed namespace declaration.
For a more automated approach, consider using SVGO or similar SVG optimization tools, which strip out editor metadata and unnecessary namespace declarations by default.
Examples
Incorrect — custom namespace attribute present
<svgxmlns="http://www.w3.org/2000/svg"
xmlns:serif="https://www.serif.com/"
viewBox="0 0 100 100">
<circleserif:id="MainCircle"cx="50"cy="50"r="40"fill="blue"/>
</svg>
This triggers two types of errors: xmlns:serif is not allowed on the <svg> element, and serif:id is not a recognized attribute on <circle>.
Correct — custom namespace and prefixed attributes removed
<svgxmlns="http://www.w3.org/2000/svg"
viewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Incorrect — multiple proprietary namespaces
Design tools sometimes add several custom namespaces at once:
<svgxmlns="http://www.w3.org/2000/svg"
xmlns:serif="https://www.serif.com/"
xmlns:xlink="http://www.w3.org/1999/xlink"
viewBox="0 0 200 200">
<gserif:id="Layer1">
<rectx="10"y="10"width="80"height="80"fill="red"/>
</g>
</svg>
Correct — only standard namespaces retained
<svgxmlns="http://www.w3.org/2000/svg"
viewBox="0 0 200 200">
<g>
<rectx="10"y="10"width="80"height="80"fill="red"/>
</g>
</svg>
Note that xmlns:xlink was also removed in this example. While it won't always trigger a validation error by itself, it's unnecessary if no xlink:href attributes are used — and modern HTML5 SVG usage favors plain href over xlink:href anyway.
In HTML5, SVG elements are natively supported and don't require explicit namespace declarations at all. When you write an <svg> tag inside an HTML document, the browser automatically associates it with the correct SVG namespace (http://www.w3.org/2000/svg). The xmlns:svg="http://www.w3.org/2000/svg" attribute is a prefixed namespace binding — it declares svg as a namespace prefix — which is a concept from XML/XHTML workflows that HTML5's parser does not support or recognize.
The HTML specification defines a limited set of allowed attributes on each element. Since xmlns:svg is not among them for the <svg> element (or any HTML5 element), the W3C validator flags it as invalid. The only namespace-related attribute the HTML parser tolerates on <svg> is xmlns="http://www.w3.org/2000/svg", and even that is optional — it's accepted purely for compatibility with XHTML but has no functional effect in HTML5.
This issue commonly appears when SVG code is exported from graphic editors like Inkscape or Adobe Illustrator, or when SVG files originally written as standalone XML documents are pasted directly into HTML. These tools sometimes include verbose namespace declarations that are necessary in XML contexts but invalid in HTML.
Why it matters
- Standards compliance: The HTML5 specification explicitly does not allow prefixed namespace attributes. Using them results in validation errors.
- Code cleanliness: Unnecessary attributes add clutter without any benefit, making your markup harder to read and maintain.
- Potential parsing issues: While most browsers silently ignore unrecognized attributes, relying on lenient browser behavior rather than valid markup can lead to unexpected results in edge cases or non-browser HTML consumers (e.g., email clients, content scrapers, or accessibility tools).
How to fix it
- Locate all
<svg>elements in your HTML that contain thexmlns:svgattribute. - Remove the
xmlns:svg="http://www.w3.org/2000/svg"attribute entirely. - If you're working in an HTML5 document (not XHTML), the
xmlns="http://www.w3.org/2000/svg"attribute is also optional — you can keep or remove it. - If your SVG uses other prefixed namespace declarations like
xmlns:xlink, consider replacing them with their HTML5 equivalents (e.g., usehrefinstead ofxlink:href).
Examples
Incorrect: using xmlns:svg on an SVG element
The xmlns:svg attribute triggers the validation error:
<svgxmlns="http://www.w3.org/2000/svg"xmlns:svg="http://www.w3.org/2000/svg"viewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Correct: removing the prefixed namespace
Remove xmlns:svg and keep only the standard attributes:
<svgxmlns="http://www.w3.org/2000/svg"viewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Also correct: minimal inline SVG in HTML5
In HTML5, the xmlns attribute itself is optional for inline SVG, so this is the cleanest approach:
<svgviewBox="0 0 100 100">
<circlecx="50"cy="50"r="40"fill="blue"/>
</svg>
Cleaning up multiple unnecessary namespaces
SVG exported from editors often includes several unnecessary namespace declarations. Here's a before-and-after of a typical cleanup:
Before (multiple invalid namespace attributes):
<svgxmlns="http://www.w3.org/2000/svg"xmlns:svg="http://www.w3.org/2000/svg"xmlns:xlink="http://www.w3.org/1999/xlink"viewBox="0 0 200 200">
<imagexlink:href="photo.jpg"width="200"height="200"/>
</svg>
After (cleaned up for HTML5):
<svgviewBox="0 0 200 200">
<imagehref="photo.jpg"width="200"height="200"/>
</svg>
Note that xlink:href has been replaced with href, which is the modern standard supported by all current browsers. The xmlns:xlink declaration is no longer needed either.
The xmlns:v attribute declares the XML namespace urn:schemas-microsoft-com:vml, which enabled Microsoft's proprietary Vector Markup Language in Internet Explorer versions 5 through 8. VML was a way to render vector shapes directly in HTML before SVG gained broad browser support. When working with XML-based documents (like XHTML), namespace declarations such as xmlns:v were syntactically valid. However, HTML5 is not an XML language — it has its own parsing rules and only recognizes a limited set of namespace declarations on the <html> element, specifically xmlns (for the default XHTML namespace) and xmlns:xlink (in certain SVG/MathML contexts). Any other xmlns:* attribute, including xmlns:v, xmlns:o, and xmlns:w, triggers a validation error.
Why This Is a Problem
Standards compliance: The HTML5 specification explicitly does not allow arbitrary XML namespace declarations. The W3C validator flags xmlns:v because it is not part of the HTML5 attribute set for any element.
No modern browser support: VML was only supported in Internet Explorer, which has been discontinued. No current browser renders VML content, so the namespace declaration serves no purpose.
Code cleanliness: Keeping legacy, non-functional attributes clutters your markup and can confuse developers who maintain the code. It may also cause issues with HTML parsers, linters, and build tools that enforce strict HTML5 compliance.
How to Fix It
- Remove the
xmlns:vattribute from your<html>tag (or wherever it appears). - Remove any related namespace attributes like
xmlns:o(Office namespace) orxmlns:w(Word namespace), which are also invalid in HTML5 and often appear alongsidexmlns:v. - Replace VML content with SVG if your page relied on VML for vector graphics. SVG is natively supported in all modern browsers and requires no namespace declaration on the
<html>element. - Ensure the
langattribute is set on the<html>element for accessibility, since you're already editing that line.
Examples
Invalid: Using xmlns:v on the html element
<!DOCTYPE html>
<htmlxmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word">
<head>
<title>My Page</title>
</head>
<body>
<p>Hello world</p>
</body>
</html>
This triggers multiple validation errors — one for each xmlns:* attribute that HTML5 does not recognize.
Valid: Namespace attributes removed
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My Page</title>
</head>
<body>
<p>Hello world</p>
</body>
</html>
Replacing VML with SVG
If your page used VML to draw shapes, replace the VML markup with inline SVG. No namespace declaration on <html> is needed — the <svg> element carries its own namespace implicitly in HTML5.
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Vector Graphics with SVG</title>
</head>
<body>
<svgwidth="200"height="200"aria-label="Blue circle">
<circlecx="100"cy="100"r="80"fill="steelblue"/>
</svg>
</body>
</html>
Common Sources of This Issue
This attribute frequently appears in HTML that was:
- Exported from Microsoft Word or Outlook. These applications generate HTML with VML namespace declarations for shapes, text effects, and email formatting.
- Copied from legacy templates. Older website templates and email templates sometimes included VML for rounded corners or background images in Internet Explorer.
- Generated by outdated WYSIWYG editors that targeted older IE versions.
If you're working with HTML email templates, note that some email clients (notably older Outlook desktop versions) still use the Word rendering engine and may rely on VML for certain effects like background images. In that context, you may intentionally keep VML in your email source — but be aware that the markup will not pass HTML5 validation. For web pages, there is no reason to retain these attributes.
In HTML5, the only namespace-related attribute permitted on the <html> element is xmlns with the value http://www.w3.org/1999/xhtml, and even that is optional—it exists solely for compatibility with XHTML serialization. Prefixed namespace declarations like xmlns:w, xmlns:o, xmlns:v, and similar attributes are XML features that have no meaning in the HTML syntax. They originate from Microsoft Office's HTML export, which generates markup containing proprietary XML namespaces such as urn:schemas-microsoft-com:office:word for Word-specific elements and styling.
Why This Is a Problem
Standards compliance: The HTML living standard (WHATWG) explicitly does not support custom namespace declarations. Including them makes your document non-conforming, and the W3C validator will report an error for each one.
No browser benefit: Modern browsers parsing HTML5 ignore these namespace declarations entirely. The attributes serve no functional purpose on the web—they only add unnecessary bloat to your markup.
Maintenance and readability: Office-generated HTML is notoriously verbose. Leaving namespace declarations in place often goes hand-in-hand with other Office artifacts (conditional comments, <o:p> tags, mso- style properties) that clutter your code and make it harder to maintain.
Accessibility and interoperability: While browsers typically tolerate these extra attributes without visible issues, non-browser HTML consumers—such as screen readers, search engine crawlers, or email clients—may handle unexpected attributes unpredictably.
How to Fix It
- Remove the
xmlns:wattribute from your<html>tag or any other element where it appears. - Remove related namespace declarations like
xmlns:o(Office),xmlns:v(VML), andxmlns:m(Math) if present. - Clean up Office-specific elements such as
<w:Sdt>,<o:p>, or<v:shape>that depend on those namespaces—these are not valid HTML elements. - Strip Office-specific CSS properties prefixed with
mso-(e.g.,mso-bidi-font-family) that often accompany namespace declarations.
If you regularly paste content from Microsoft Word, consider using a "paste as plain text" feature in your editor, or use an HTML cleaning tool to strip Office artifacts automatically.
Examples
Invalid: Office namespace on the <html> element
<!DOCTYPE html>
<htmllang="en"xmlns:w="urn:schemas-microsoft-com:office:word">
<head>
<title>Document</title>
</head>
<body>
<p>Content from Word</p>
</body>
</html>
Invalid: Multiple Office namespaces
<!DOCTYPE html>
<htmllang="en"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:v="urn:schemas-microsoft-com:vml">
<head>
<title>Document</title>
</head>
<body>
<pclass="MsoNormal">Content from Word<o:p></o:p></p>
</body>
</html>
Valid: Clean HTML without namespace declarations
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Document</title>
</head>
<body>
<p>Content from Word</p>
</body>
</html>
Valid: Using the standard xmlns attribute (optional)
If you need XHTML compatibility, the standard xmlns attribute (without a prefix) is permitted:
<!DOCTYPE html>
<htmllang="en"xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Document</title>
</head>
<body>
<p>Content from Word</p>
</body>
</html>
Note that this same validation error applies to any custom prefixed namespace attribute—not just xmlns:w. If you see similar errors for xmlns:o, xmlns:v, xmlns:st1, or others, the fix is the same: remove them along with any elements or attributes that depend on those namespaces.
The < character is the opening delimiter for HTML tags. When the browser's HTML parser encounters <, it expects a valid tag name to follow (like div, p, span, etc.). If it instead finds an unexpected character—a digit, a symbol, a space, or anything that doesn't form a recognized tag—the parser enters an error state. The validator flags this because the < was almost certainly meant as literal content, not as the start of a tag.
This issue commonly appears in several scenarios:
- Mathematical or comparison expressions like
x < yorif (count < 10) - Inline code or technical content that includes angle brackets, such as explaining generics (
List<String>) or template syntax - User-generated content or CMS output where text hasn't been properly HTML-encoded
- Copy-pasting code snippets directly into HTML without escaping
Beyond triggering validation errors, unescaped < characters can cause real rendering problems. The browser may try to interpret the text following < as a tag, swallowing part of your visible content or producing unexpected DOM structures. This can also create accessibility issues, as screen readers rely on a well-formed DOM to convey content accurately.
How to fix it
Replace every < that appears as content (not as part of an actual HTML tag) with the HTML entity <. Similarly, replace literal > with >. While > doesn't always cause validation errors, escaping both characters is a best practice that prevents ambiguity and keeps your markup clean.
If you're writing code examples, wrap them in <code> or <pre> elements—but note that you still need to escape < and > inside those elements. The <pre> and <code> tags preserve whitespace and indicate code semantics, but they do not disable HTML parsing.
Examples
❌ Bad: unescaped < in a math expression
<p>Check if x <10beforeproceeding.</p>
The parser sees < 10 and tries to interpret 10 as a tag name, triggering the error.
✅ Fixed: escaped with <
<p>Check if x < 10 before proceeding.</p>
❌ Bad: unescaped angle brackets in a code snippet
<pre><code>
List<String> names = new ArrayList<String>();
</code></pre>
The parser interprets <String> as an unknown HTML tag, breaking the content.
✅ Fixed: all angle brackets escaped inside <code>
<pre><code>
List<String> names = new ArrayList<String>();
</code></pre>
❌ Bad: unescaped < in a conditional expression
<p>The expression 1 <2&&3> 1 evaluates to true.</p>
✅ Fixed: both < and > escaped
<p>The expression 1 < 2 && 3 > 1 evaluates to true.</p>
Note that && also needs to be escaped as && because & is itself a reserved character in HTML.
Quick reference for common HTML entities
| Character | Entity | Description |
|---|---|---|
< | < | Less-than sign |
> | > | Greater-than sign |
& | & | Ampersand |
" | " | Double quotation mark |
If you're generating HTML dynamically (via JavaScript, a server-side language, or a CMS), make sure your output pipeline includes an HTML-encoding step. Most frameworks and template engines provide a built-in escaping function—use it for any user-supplied or variable content that gets inserted into HTML.
The <noscript> element behaves differently depending on where it appears in a document. When placed inside the <head>, it can only contain <link>, <style>, and <meta> elements — strictly metadata content. When placed inside the <body>, it can contain any flow content, including <p>, <div>, <iframe>, and more. This distinction is defined in the WHATWG HTML Living Standard.
When the validator encounters an <iframe> inside a <noscript> in the <head>, it reports "Bad start tag" because the parser is operating under the <head> content model, where <iframe> is simply not a valid element. The browser may attempt error recovery by implicitly closing the <head> and opening the <body>, but this can lead to unexpected DOM structures and layout issues.
This pattern commonly appears when adding tracking or analytics snippets. For instance, Google Tag Manager provides a <noscript> fallback containing an <iframe>, and it's meant to be placed immediately after the opening <body> tag — not in the <head>. Placing it in the wrong location breaks validation and may cause the tracking pixel to malfunction.
To fix the error, identify any <noscript> blocks in your <head> that contain non-metadata elements (like <iframe>, <p>, <div>, <img>, etc.) and move them into the <body>. If the <noscript> block only needs metadata elements like <meta> or <style>, it can remain in the <head>.
Examples
Invalid: iframe inside noscript in head
The <iframe> is not valid metadata content, so it cannot appear inside <noscript> within the <head>.
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My webpage</title>
<noscript>
<iframesrc="https://example.com/tracking"></iframe>
</noscript>
</head>
<body>
<h1>Welcome</h1>
</body>
</html>
Fixed: noscript with iframe moved to body
Moving the <noscript> block into the <body> resolves the error, since flow content is allowed there.
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My webpage</title>
</head>
<body>
<noscript>
<iframesrc="https://example.com/tracking"></iframe>
</noscript>
<h1>Welcome</h1>
</body>
</html>
Valid: metadata-only noscript in head
A <noscript> block that contains only metadata elements is perfectly valid inside the <head>.
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My webpage</title>
<noscript>
<metahttp-equiv="refresh"content="0; url=https://example.com/nojs">
<style>
.js-only{display: none;}
</style>
</noscript>
</head>
<body>
<h1>Welcome</h1>
</body>
</html>
Fixed: splitting a mixed noscript between head and body
If you need both metadata and flow content in your <noscript> fallback, use two separate <noscript> blocks — one in the <head> for metadata, and one in the <body> for visible content.
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My webpage</title>
<noscript>
<style>
.js-only{display: none;}
</style>
</noscript>
</head>
<body>
<noscript>
<p>Please enable JavaScript to view this website.</p>
<iframesrc="https://example.com/tracking"></iframe>
</noscript>
<h1>Welcome</h1>
</body>
</html>
The <noscript> element provides fallback content for users whose browsers don't support scripting or have JavaScript disabled. When <noscript> appears inside <head>, the HTML specification restricts its contents to metadata elements only — specifically <link>, <style>, and <meta>. An <img> tag is flow content, not metadata content, so it is not permitted inside <head> regardless of whether it's wrapped in <noscript>.
When <noscript> appears inside <body>, however, it can contain any flow content that would normally be valid at that position — including <img> elements. This is why the fix is simply to relocate the <noscript> block from the <head> to the <body>.
This issue is extremely common with third-party tracking pixels. Services like Facebook Pixel, LinkedIn Insight Tag, Google Tag Manager, and similar tools often instruct you to paste a <noscript> block containing a 1×1 tracking <img> directly after the opening <head> tag. While this works in browsers (they are forgiving with invalid HTML), it does not conform to the HTML specification and will trigger a validation error.
Beyond standards compliance, keeping your HTML valid ensures predictable behavior across all browsers and assistive technologies. Invalid markup can lead to unexpected DOM construction, which may cause subtle issues with CSS selectors, JavaScript DOM queries, or accessibility tools.
How to Fix It
- Locate the
<noscript>block that contains the<img>element inside your<head>. - Move that entire
<noscript>block to somewhere inside the<body>— typically right after the opening<body>tag. - Keep any associated
<script>tag in the<head>if desired; only the<noscript>with the<img>needs to move.
Examples
❌ Invalid: <img> inside <noscript> in <head>
This is the pattern commonly provided by third-party tracking pixel instructions:
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My Page</title>
<script>
/* tracking script */
</script>
<noscript>
<imgsrc="https://example.com/pixel?id=123"height="1"width="1"alt="">
</noscript>
</head>
<body>
<h1>Welcome</h1>
</body>
</html>
The validator reports "Bad start tag in img in noscript in head" because <img> is not valid metadata content.
✅ Valid: <noscript> with <img> moved to <body>
Move the <noscript> block into the <body> while leaving the <script> in the <head>:
<!DOCTYPE html>
<htmllang="en">
<head>
<title>My Page</title>
<script>
/* tracking script */
</script>
</head>
<body>
<noscript>
<imgsrc="https://example.com/pixel?id=123"height="1"width="1"alt="">
</noscript>
<h1>Welcome</h1>
</body>
</html>
The <img> is now inside <body> (via <noscript>), where flow content is permitted. The tracking pixel will still function correctly for users with JavaScript disabled.
✅ Valid: metadata-only <noscript> in <head>
If you only need metadata fallback content in the <head>, elements like <meta>, <link>, and <style> are allowed:
<head>
<title>My Page</title>
<noscript>
<style>
.js-only{display: none;}
</style>
</noscript>
</head>
This is valid because <style> is metadata content. Use this pattern when you need to apply fallback styles for non-JavaScript users, and reserve <noscript> blocks with <img> or other flow content for the <body>.
The HTML specification defines two distinct content models for the <noscript> element based on its location in the document. When <noscript> appears inside <head>, it inherits the restrictions of the <head> element itself — only metadata content is permitted. This means elements like <link>, <style>, and <meta> are allowed, but flow content like <p>, <div>, <h1>, or any other body-level element is not. When <noscript> appears inside <body>, it follows the more permissive rules of flow content and can contain paragraphs, headings, and other visible elements.
This distinction exists because the <head> section is strictly reserved for metadata that describes the document — it is never rendered as visible page content. Placing a <p> tag inside a <noscript> in <head> violates this principle. Browsers may handle this inconsistently: some might silently ignore the invalid content, while others might force the <head> to close prematurely and push the content into the <body>, causing unexpected layout issues and potentially disrupting other metadata elements that follow.
This is also an accessibility concern. Screen readers and other assistive technologies rely on a well-structured document where the <head> contains only metadata and all visible content lives in the <body>. Invalid nesting can confuse these tools and lead to content being skipped or misinterpreted.
How to Fix It
You have two main approaches:
Keep
<noscript>in<head>but use only metadata elements. This is ideal when you need to load a fallback stylesheet or add a<meta>redirect for users without JavaScript.Move the
<noscript>block into<body>if you need to display visible text or other flow content to the user.
Examples
❌ Incorrect: Flow content inside <noscript> in <head>
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Example</title>
<noscript>
<p>JavaScript is disabled.</p>
</noscript>
</head>
<body>
</body>
</html>
The <p> element is flow content and is not allowed inside <noscript> when it sits within <head>.
✅ Correct: Metadata-only <noscript> in <head>
If your goal is to provide a fallback stylesheet or redirect when JavaScript is unavailable, use only metadata elements:
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Example</title>
<noscript>
<linkrel="stylesheet"href="no-js-fallback.css">
</noscript>
</head>
<body>
</body>
</html>
You can also use <style> or <meta> inside the <noscript> in <head>:
<head>
<title>Example</title>
<noscript>
<style>
.js-only{display: none;}
.no-js-message{display: block;}
</style>
</noscript>
</head>
✅ Correct: Textual fallback in <noscript> inside <body>
When you need to show a visible message to users who have JavaScript disabled, place the <noscript> block in the <body>:
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Example</title>
</head>
<body>
<noscript>
<p>This site requires JavaScript to function properly. Please enable JavaScript in your browser settings.</p>
</noscript>
</body>
</html>
✅ Correct: Combining both approaches
For a comprehensive fallback strategy, you can use <noscript> in both locations — metadata in <head> and visible content in <body>:
<!DOCTYPE html>
<htmllang="en">
<head>
<title>Example</title>
<noscript>
<linkrel="stylesheet"href="no-js-fallback.css">
</noscript>
</head>
<body>
<noscript>
<p>JavaScript is disabled. Some features may not be available.</p>
</noscript>
</body>
</html>
This gives you the best of both worlds: styling adjustments via the <head> fallback and a user-facing message via the <body> fallback.
The aria-rowspan attribute is used in ARIA-based grid and table structures to indicate how many rows a cell spans. It serves a similar purpose to the rowspan attribute on native HTML <td> and <th> elements, but is designed for custom widgets built with ARIA roles like gridcell, rowheader, and columnheader within grid or treegrid structures.
According to the WAI-ARIA specification, the value of aria-rowspan must be a positive integer — a whole number greater than zero. A value of "0" is invalid because it implies the cell spans no rows, which is semantically meaningless. Note that this differs from native HTML's rowspan attribute, where "0" has a special meaning (span all remaining rows in the row group). The ARIA attribute does not support this behavior.
This matters primarily for accessibility. Screen readers and other assistive technologies rely on aria-rowspan to convey the structure of custom grids to users. An invalid value of "0" can confuse assistive technology, potentially causing it to misrepresent the grid layout or skip the cell entirely. Ensuring valid values helps users who depend on these tools navigate your content correctly.
To fix this issue, determine how many rows the cell actually spans and set aria-rowspan to that number. If the cell occupies a single row, use "1". If it spans multiple rows, use the appropriate count. If you don't need row spanning at all, you can simply remove the aria-rowspan attribute entirely, since the default behavior is to span one row.
Examples
Incorrect: aria-rowspan set to zero
<divrole="grid">
<divrole="row">
<divrole="gridcell"aria-rowspan="0">Name</div>
<divrole="gridcell">Value</div>
</div>
</div>
The value "0" is not a positive integer, so the validator reports an error.
Correct: aria-rowspan set to a positive integer
If the cell spans a single row, use "1" (or remove the attribute, since one row is the default):
<divrole="grid">
<divrole="row">
<divrole="gridcell"aria-rowspan="1">Name</div>
<divrole="gridcell">Value</div>
</div>
</div>
Correct: aria-rowspan for a cell spanning multiple rows
If the cell genuinely spans two rows, set the value accordingly:
<divrole="grid">
<divrole="row">
<divrole="gridcell"aria-rowspan="2">Category</div>
<divrole="gridcell">Item A</div>
</div>
<divrole="row">
<divrole="gridcell">Item B</div>
</div>
</div>
Correct: removing the attribute when no spanning is needed
If the cell doesn't span multiple rows, the simplest fix is to remove aria-rowspan altogether:
<divrole="grid">
<divrole="row">
<divrole="gridcell">Name</div>
<divrole="gridcell">Value</div>
</div>
</div>
When to use aria-rowspan vs. native HTML
If you're building a data table, prefer native HTML <table>, <tr>, <td>, and <th> elements with the standard rowspan attribute. Native table semantics are automatically understood by browsers and assistive technologies without any ARIA attributes. Reserve aria-rowspan for custom interactive widgets (like spreadsheet-style grids or tree grids) where native table elements aren't appropriate. The aria-rowspan value should always match the actual visual and structural layout of your grid to avoid confusing assistive technology users.
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