HTML Guides for namespace
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.
Namespace declarations like xmlns:dc on an <svg> element are not serializable as XML 1.0 when used in an HTML5 document.
In HTML5 (the text/html serialization), namespace declarations using the xmlns: prefix syntax are not valid attributes. The HTML parser does not treat these as actual XML namespace declarations — it sees them as regular attributes with a colon in the name, which cannot be serialized back to well-formed XML 1.0. This commonly happens when SVG code is exported from graphic editors like Inkscape or Adobe Illustrator, which include Dublin Core (dc), RDF, and other XML namespace declarations that are unnecessary for rendering.
The SVG will render perfectly fine in browsers without these namespace prefixes. If the <svg> element doesn't actually use any elements or attributes from those namespaces (like <dc:title>), you can safely remove them. If it does contain such elements, those elements are also typically unused by browsers and can be removed as well.
Invalid Example
<svg xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
viewBox="0 0 100 100">
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="">
<dc:title>My Icon</dc:title>
</rdf:Description>
</rdf:RDF>
</metadata>
<circle cx="50" cy="50" r="40" fill="blue" />
</svg>
Valid Example
Remove the namespace declarations and any associated metadata elements:
<svg viewBox="0 0 100 100">
<circle cx="50" cy="50" r="40" fill="blue" />
</svg>
If you still want to provide a title for accessibility, use the standard SVG <title> element instead:
<svg viewBox="0 0 100 100" role="img">
<title>My Icon</title>
<circle cx="50" cy="50" r="40" fill="blue" />
</svg>
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>
<html xmlns: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>
<html lang="en">
<head>
<meta charset="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:
<div xmlns: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>
<html lang="en">
<head>
<meta charset="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 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
<svg xmlns: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:namedview pagecolor="#ffffff" />
<circle cx="50" cy="50" r="40" fill="blue"
inkscape:label="Main Circle" />
</svg>
✅ Valid: Cleaned SVG without editor-specific namespaces
<svg viewBox="0 0 100 100">
<circle cx="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
<svg xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<circle cx="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
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<circle cx="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:
<svg viewBox="0 0 100 100">
<circle cx="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>
<html xmlns: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:oval style="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>
<html lang="en">
<head>
<title>Modern SVG Page</title>
</head>
<body>
<svg width="100" height="75" xmlns="http://www.w3.org/2000/svg">
<ellipse cx="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>
<html lang="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.
The xmlns:msdt attribute is a Microsoft Office namespace declaration, and HTML doesn't allow prefixed namespace declarations on any element.
In XML, xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" binds the prefix msdt to Microsoft's data types namespace. Office uses it to give each document property a type, with attributes like msdt:dt="string". The HTML parser doesn't process namespace declarations, so it reads xmlns:msdt as an unknown attribute that happens to have a colon in its name. The only namespace attribute HTML accepts is xmlns, with the exact value http://www.w3.org/1999/xhtml. The validator reports xmlns:msdt on any element, <html> included.
The declaration usually comes with a block of Office document properties, which SharePoint and Office write into the pages they save. The block has its own <html> and <head> tags, often with xmlns:mso next to xmlns:msdt, and keeps the properties inside a conditional comment that browsers treat as a plain comment. When the block ends up in the middle of a page, the validator also reports the stray <html> and <head> tags. Browsers drop the extra <head> tags and copy the attributes of the extra <html> tag onto the page's real <html> element.
Remove the whole block: the extra <html> and <head> tags and the comment between them. If xmlns:msdt sits on the page's own <html> tag instead, delete just the attribute. Browsers don't use the declaration or the properties, so the page looks and works the same without them. If the block comes from a SharePoint page layout, remove it from the layout so every page that uses it gets the fix. If it comes from content pasted into a web part, edit that content.
Invalid example
<div class="page-content">
<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"><head>
<!--[if gte mso 9]><xml>
<mso:CustomDocumentProperties>
<mso:ContentType msdt:dt="string">Page</mso:ContentType>
</mso:CustomDocumentProperties>
</xml><![endif]-->
</head>
<p>Our offices are open Monday to Friday.</p>
</div>
Valid example
<div class="page-content">
<p>Our offices are open Monday to Friday.</p>
</div>
The xmlns:mso attribute is an XML namespace declaration that SharePoint writes into the pages and files it stores, and HTML doesn't accept it on any element.
In XML, xmlns:mso="urn:schemas-microsoft-com:office:office" binds the prefix mso to the Microsoft Office namespace, the same namespace Word binds to o. SharePoint uses that prefix for page properties such as the content type or the contact name, stored as mso: elements inside <mso:CustomDocumentProperties>.
HTML elements don't take namespace declarations. The parser treats xmlns:mso as an ordinary attribute that happens to have a colon in its name, and no HTML element defines an attribute by that name. The one namespace attribute an HTML element may carry is xmlns, and only with the value http://www.w3.org/1999/xhtml, so the validator reports xmlns:mso even on the page's own <html> tag.
Most of the time the attribute arrives inside a block of SharePoint properties that ends up in the page: a second <html> tag with xmlns:mso (often next to xmlns:msdt), a <head> tag, and the properties wrapped in a <!--[if gte mso 9]> conditional comment. The mso in that comment is Office's version check, unrelated to the namespace prefix, and browsers read the whole comment as a plain comment. When the block sits inside the body, the validator also reports the stray <html> and <head> tags. Browsers skip the extra <head> tags and copy the extra <html> tag's attributes onto the page's real <html> element.
Delete the whole block: the extra <html> and <head> tags and the comment between them. If xmlns:mso is on the page's own <html> tag, delete only the attribute. Browsers ignore the declaration and the properties, so removing them doesn't change how the page looks or behaves. Edit the file the block lives in. When every page built from the same page layout or master page shows it, fix that layout or master page. When only one page has it, look in the HTML file or web part content that page pulls in.
Invalid example
<div class="page-content">
<html xmlns:mso="urn:schemas-microsoft-com:office:office"><head>
<!--[if gte mso 9]><xml>
<mso:CustomDocumentProperties>
<mso:PublishingContactName>Web team</mso:PublishingContactName>
</mso:CustomDocumentProperties>
</xml><![endif]-->
</head>
<p>Our offices are open Monday to Friday.</p>
</div>
Valid example
<div class="page-content">
<p>Our offices are open Monday to Friday.</p>
</div>
The xmlns:pcm attribute is an XML namespace declaration, and HTML doesn't allow prefixed namespace declarations on any element.
In XML, xmlns:pcm="urn:PageContentManager" binds the prefix pcm to that namespace, so names like pcm:item can appear inside the element. The HTML parser doesn't process namespace declarations. It keeps xmlns:pcm as a plain attribute with a colon in its name. The only namespace attribute an HTML element may have is xmlns, with the exact value http://www.w3.org/1999/xhtml. The validator reports xmlns:pcm wherever it appears, <html> included.
The attribute shows up in pages built with XSLT, such as SharePoint web parts. When an XSLT stylesheet writes out a literal element, it copies the namespace declarations in scope onto that element, except for the XSLT namespace itself and any prefix listed in exclude-result-prefixes. If you can edit the stylesheet, add pcm to that list:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:pcm="urn:PageContentManager"
exclude-result-prefixes="pcm">
Browsers do nothing with the attribute, so removing it doesn't change how the page looks or works.
Invalid example
<div class="news-list" xmlns:pcm="urn:PageContentManager">
<ul>
<li><a href="/news/opening-hours">Opening hours change</a></li>
</ul>
</div>
Valid example
<div class="news-list">
<ul>
<li><a href="/news/opening-hours">Opening hours change</a></li>
</ul>
</div>
The xmlns:style attribute declares an XML namespace prefix, and HTML elements don't accept namespace declarations other than xmlns itself.
In XML, xmlns:style="..." binds the prefix style to a namespace URI, so the document can use names like style:font. The HTML parser doesn't process namespace declarations. It reads xmlns:style as an ordinary attribute with an unusual name and does nothing with it. The one namespace attribute an HTML element may have is xmlns, and only with the exact value http://www.w3.org/1999/xhtml. The validator rejects prefixed declarations like xmlns:style on every HTML element, <html> included.
The attribute usually comes from markup generated with XML tools. An XSLT stylesheet, for example, copies the namespace declarations in scope onto each literal element it outputs, unless the prefix is listed in exclude-result-prefixes:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:style="http://www.w3.org/1999/xhtml"
exclude-result-prefixes="style">
When a template repeats the declaration on the same element, the validator also reports a duplicate attribute error. Removing xmlns:style fixes both, and the page renders the same because the attribute has no effect in browsers.
Invalid example
<div class="top-bar" xmlns:style="http://www.w3.org/1999/xhtml">
<a href="/">Home</a>
</div>
Valid example
<div class="top-bar">
<a href="/">Home</a>
</div>
The xmlns:web attribute is an XML namespace declaration for a web prefix, and HTML doesn't allow prefixed namespace declarations on any element.
In XML, xmlns:web="http://example.com/schemas/web/" binds the prefix web to a namespace, so names like web:result can appear in the document. The URI identifies the namespace, and web is only a short alias the template's author picked. On the root <html> tag, the declaration is typically left over from a template first written as XHTML, where it sat next to xmlns="http://www.w3.org/1999/xhtml" and xml:lang.
The HTML parser doesn't process namespace declarations. It keeps xmlns:web as a plain attribute with a colon in its name, and it lowercases the name, so the validator reports xmlns:web even when the source says xmlns:Web. The only namespace attribute HTML accepts is xmlns, with the exact value http://www.w3.org/1999/xhtml. That one is allowed but does nothing in an HTML page, so you can keep it or drop it.
Delete xmlns:web from the tag. Browsers don't act on the declaration, so removing it doesn't change how the page looks or works. If the markup also has web: attributes, the validator reports each of them as not allowed. Move that data into data-* attributes, or remove it if nothing reads it.
Invalid example
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:Web="http://example.com/schemas/web/">
<head>
<title>Search results</title>
</head>
<body>
<p>Results for your search.</p>
</body>
</html>
Valid example
<!DOCTYPE html>
<html lang="en">
<head>
<title>Search results</title>
</head>
<body>
<p>Results for your search.</p>
</body>
</html>
An attribute like xmlns:news or xmlns:x declares an XML namespace prefix, and HTML doesn't accept prefixed namespace declarations, except xmlns:xlink on SVG and MathML elements.
In XML, xmlns:news="http://example.com/modules/news" binds the prefix news to a namespace URI, so names like news:item can appear in the document. The HTML parser doesn't process namespace declarations. It keeps the declaration as a plain attribute with a colon in its name, and it lowercases that name, so xmlns:Foo in the source shows up as xmlns:foo in the message. The validator reports it the same way whatever the prefix is and whichever element carries it, <html> included. On HTML elements the only namespace attribute allowed is xmlns, with the exact value http://www.w3.org/1999/xhtml. Inline <svg> and <math> also accept xmlns:xlink="http://www.w3.org/1999/xlink", and no other prefix.
Pages built with XSLT, as many CMS modules are, often carry these declarations on a <div> or on <html>. When an XSLT stylesheet writes out a literal element, it copies the namespace declarations in scope onto that element, except for the XSLT namespace itself and any prefix listed in exclude-result-prefixes. If you can edit the stylesheet, add the prefix to that list:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:news="http://example.com/modules/news"
exclude-result-prefixes="news">
Inline SVG pasted from Adobe Illustrator brings its own set: xmlns:x, xmlns:i and xmlns:graph on the root <svg>, pointing to Adobe's Extensibility, Illustrator and Graphs namespaces, and in older files xmlns:a for the Adobe SVG Viewer plugin. In the original .svg file the values are often entity references like &ns_ai;, defined in the file's DOCTYPE, so they don't resolve to anything once the markup sits inside an HTML page. Delete the declarations along with any attributes that use those prefixes, such as i:extraneous="self" on a <g>, which the validator reports as a separate error. If a build step inlines your SVGs, SVGO's removeEditorsNSData plugin, part of its default preset, removes Adobe's namespaces and the attributes that use them.
Browsers ignore these declarations in HTML, so removing them doesn't change how the page looks or works.
Invalid example
<div class="news-list" xmlns:news="http://example.com/modules/news">
<p>Latest news</p>
</div>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:x="http://ns.adobe.com/Extensibility/1.0/"
xmlns:i="http://ns.adobe.com/AdobeIllustrator/10.0/"
xmlns:graph="http://ns.adobe.com/Graphs/1.0/"
width="24" height="24" viewBox="0 0 24 24">
<path d="M5 12l5 5L20 7" fill="none" stroke="currentColor" stroke-width="2" />
</svg>
Valid example
<div class="news-list">
<p>Latest news</p>
</div>
<svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24">
<path d="M5 12l5 5L20 7" fill="none" stroke="currentColor" stroke-width="2" />
</svg>
The xmlns attribute declares the XML namespace for an element. For SVG elements, the only permitted namespace is "http://www.w3.org/2000/svg". When this attribute is present but set to an empty string ("") or any value other than the correct namespace, the W3C validator reports an error because the browser cannot properly associate the element with the SVG specification.
In HTML5 documents (served as text/html), the xmlns attribute on <svg> is actually optional. The HTML parser automatically associates <svg> elements with the correct SVG namespace without needing an explicit declaration. However, if you do include the xmlns attribute — for example, because your SVG was exported from a design tool or copied from an XML-based source — it must contain the exact value "http://www.w3.org/2000/svg". An empty or incorrect value will cause a validation error and could lead to rendering issues in certain contexts.
This matters for several reasons:
- Standards compliance: The HTML specification explicitly restricts the allowed value for
xmlnson SVG elements. - Browser compatibility: While most modern browsers are forgiving in HTML mode, an incorrect namespace can cause problems when SVG content is used in XML contexts (such as XHTML or standalone
.svgfiles). - Interoperability: Tools and libraries that process your HTML may rely on the correct namespace to identify and manipulate SVG elements.
To fix this issue, you have two options:
- Set the correct value: Replace the empty or incorrect
xmlnsvalue with"http://www.w3.org/2000/svg". - Remove the attribute entirely: Since
xmlnsis optional in HTML5, simply removing it is often the cleanest solution.
Examples
Incorrect: empty xmlns attribute
This triggers the validation error because the namespace value is an empty string:
<svg xmlns="" width="100" height="100">
<circle cx="50" cy="50" r="40" fill="red" />
</svg>
Incorrect: wrong namespace value
Any value other than the correct SVG namespace will also trigger this error:
<svg xmlns="http://www.w3.org/2000/html" width="100" height="100">
<circle cx="50" cy="50" r="40" fill="red" />
</svg>
Fix: use the correct namespace
Set xmlns to the only permitted value:
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
<circle cx="50" cy="50" r="40" fill="red" />
</svg>
Fix: remove the xmlns attribute
In an HTML5 document, you can omit xmlns altogether since the parser handles the namespace automatically:
<svg width="100" height="100">
<circle cx="50" cy="50" r="40" fill="red" />
</svg>
Note on inline SVG from external sources
Design tools like Figma, Illustrator, or Inkscape often export SVG files with the xmlns attribute already set correctly. If you're copying SVG markup and the xmlns value gets accidentally cleared or corrupted during the process, either restore it to "http://www.w3.org/2000/svg" or remove it before embedding the SVG in your HTML. Both approaches will produce valid, working markup.
The xmlns attribute has the XHTML namespace written with https://, but the only allowed value is http://www.w3.org/1999/xhtml.
A namespace name looks like a web address, yet no browser ever loads it. Parsers treat it as a fixed name and compare it character by character, so https://www.w3.org/1999/xhtml names a different namespace than the HTML one. The https usually slips in when a site moves to HTTPS. A search and replace across the templates, or a plugin that upgrades every http:// string, changes the namespace along with the real links. The SVG and MathML namespaces keep http:// too.
In a page served as text/html, the parser puts every element in the HTML namespace by itself, and the HTML standard says xmlns has no effect there, which is why the page still renders. The value matters once the same markup is parsed as XML, for example when it's served as application/xhtml+xml or run through XSLT. Its elements then land in an unknown namespace, and browsers and XML tools no longer treat them as HTML.
Change https back to http. In a page served as HTML you can delete the attribute instead, and keep it only if the same file also has to work as XHTML. If an HTTPS rewrite caused the change, exclude namespace names from it so the next run doesn't break them again.
Invalid example
<!DOCTYPE html>
<html xmlns="https://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Products</title>
</head>
<body>
<p>Our product range.</p>
</body>
</html>
Valid example
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Products</title>
</head>
<body>
<p>Our product range.</p>
</body>
</html>
XML namespaces are identified by URI strings that act as unique names. They are never fetched or loaded by the browser — they simply serve as an identifier that must match exactly what the specification defines. The XLink namespace has been defined as http://www.w3.org/1999/xlink since its inception, and changing the protocol to https creates a completely different string that parsers and validators do not recognize.
It's a common and understandable mistake. Developers are trained to prefer https:// URLs everywhere for security, and many linting tools or habits may encourage automatically converting http:// to https://. However, namespace URIs are a special case where this rule does not apply. The string is purely declarative — no network request is made, and no security benefit comes from using https.
It's also worth noting that the xmlns:xlink attribute is largely obsolete in modern HTML. When SVG is embedded directly in an HTML5 document, browsers automatically handle namespace resolution. You only need xmlns:xlink when serving SVG as standalone XML (with an .svg file or application/xhtml+xml content type). In most cases, you can simply remove the attribute altogether and use xlink:href or, even better, the plain href attribute, which is now supported on SVG elements like <use>, <image>, and <a>.
Examples
Incorrect: using https:// in the namespace URI
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink">
<use xlink:href="#icon-star"></use>
</svg>
This triggers the validation error because https://www.w3.org/1999/xlink does not match the required namespace identifier.
Fixed: using the correct http:// namespace URI
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<use xlink:href="#icon-star"></use>
</svg>
Preferred: removing the namespace and using plain href
In HTML5, you can drop the xmlns:xlink declaration entirely and use the standard href attribute instead of xlink:href:
<svg xmlns="http://www.w3.org/2000/svg">
<use href="#icon-star"></use>
</svg>
This is the cleanest approach for inline SVG in modern HTML documents. The xlink:href attribute is deprecated in SVG 2, and all modern browsers support plain href on SVG linking elements.
An XML namespace URI is a unique identifier, not an actual web address that your browser fetches. The SVG namespace was defined as http://www.w3.org/2000/svg in the original SVG specification, and that exact string is what HTML parsers and validators expect. Even though using https everywhere is a best practice for real network requests, namespace URIs are not network requests — they are simply fixed strings used to identify which XML vocabulary an element belongs to.
When you write https://www.w3.org/2000/svg instead of http://www.w3.org/2000/svg, the validator sees an unrecognized namespace. This can also cause problems in certain XML-based contexts (such as XHTML or standalone SVG files), where the browser may fail to recognize the element as SVG at all, resulting in your graphics not rendering. In standard HTML5 mode, most browsers will still render inline SVGs correctly regardless of the xmlns value, but the markup is technically invalid and may cause issues in stricter parsing environments like XML serializers, server-side renderers, or tools that process SVG as XML.
This mistake is especially common because many developers reflexively change http to https — or their editor or linter automatically does — when they see a URL-like string. The same principle applies to other namespace URIs like http://www.w3.org/1999/xhtml for HTML and http://www.w3.org/1998/Math/MathML for MathML. These are all fixed identifiers that must not be altered.
How to Fix It
Replace https:// with http:// in the xmlns attribute value. That's it — no other changes are needed.
If your project uses automated tooling that rewrites http URLs to https, you may need to configure an exception for XML namespace URIs.
Examples
❌ Incorrect: Using https in the namespace URI
<svg xmlns="https://www.w3.org/2000/svg" viewBox="0 0 100 100">
<circle cx="50" cy="50" r="40" fill="blue" />
</svg>
This triggers the validation error because https://www.w3.org/2000/svg is not a recognized namespace value.
✅ Correct: Using http in the namespace URI
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<circle cx="50" cy="50" r="40" fill="blue" />
</svg>
✅ Correct: Inline SVG in HTML without xmlns
When embedding SVG directly inside an HTML5 document, the xmlns attribute is optional — the HTML parser automatically assigns the correct namespace to <svg> elements:
<svg viewBox="0 0 100 100">
<circle cx="50" cy="50" r="40" fill="blue" />
</svg>
This is perfectly valid HTML5. You only need the xmlns attribute when the SVG is served as a standalone .svg file or used within an XHTML document.
The xmlns:xlink attribute on inline SVG accepts only one value, http://www.w3.org/1999/xlink.
The message calls the attribute xmlns:link, but the one to look for in your markup is xmlns:xlink. It declares the XLink namespace, which SVG 1.1 used for attributes such as xlink:href. A namespace URI is a fixed name that the browser never loads, so it has to match the specification character for character. A different year, a trailing slash, https instead of http, or a path segment rewritten by a build tool or a search and replace all trigger this error.
In an HTML document you don't need the declaration at all. The HTML parser puts xlink:href and the other xlink: attributes in the XLink namespace by itself, and SVG 2 lets you write plain href on <use>, <image> and <a>. Either correct the value or remove the attribute and switch xlink:href to href.
Invalid example
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/2000/xlink" viewBox="0 0 24 24" width="24" height="24">
<use xlink:href="#icon-star"></use>
</svg>
Valid example
Correct the namespace URI:
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 24 24" width="24" height="24">
<use xlink:href="#icon-star"></use>
</svg>
Or drop the declaration and use href:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
<use href="#icon-star"></use>
</svg>
On <svg> and the elements inside it, the xmlns attribute can only hold the SVG namespace, http://www.w3.org/2000/svg.
When the HTML parser reads inline SVG, it places <svg> and its descendants in the SVG namespace by itself, whatever xmlns says. The main exception is content inside <foreignObject>, which is parsed as HTML. Because the attribute can't change the namespace, the HTML standard makes any other value a parse error, whether it sits on the <svg> element or on a child such as <g> or <path>. A trailing slash or the XHTML namespace triggers it just like an unrelated URI does.
Design tools are a common source. Adobe Illustrator can export a <metadata> block holding an <sfw> element declared in its own Save for Web namespace, http://ns.adobe.com/SaveForWeb/1.0/. In a standalone .svg file, which is parsed as XML, that declaration puts <sfw> in Adobe's namespace. Pasted into HTML, the declaration has no effect and <sfw> becomes an unknown SVG element, so the validator also reports sfw and slices as unknown elements. Browsers don't render <metadata>, so deleting the block leaves the graphic unchanged, and SVG optimizers such as SVGO remove it by default.
For the attribute itself, either set it to exactly http://www.w3.org/2000/svg or remove it, because inline SVG in HTML doesn't need it.
Invalid example
<svg viewBox="0 0 24 24" width="24" height="24">
<metadata>
<sfw xmlns="http://ns.adobe.com/SaveForWeb/1.0/">
<slices></slices>
</sfw>
</metadata>
<circle cx="12" cy="12" r="10" fill="teal"/>
</svg>
Valid example
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
<circle cx="12" cy="12" r="10" fill="teal"/>
</svg>
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.
1K Weekly
1,000 monthly checks. Cancel anytime.
Get 1K Weekly →Join teams across 40+ countries