HTML Guides - issues tagged as svg

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:serif attribute 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

xmlns:serif="http://www.serif.com/"

viewBox="0 0 100 100"

width="100"

height="100">

</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

viewBox="0 0 100 100"

width="100"

height="100">

<g>

</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:

xmlns:serif="http://www.serif.com/"

xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

viewBox="0 0 200 200">

<rect x="10" y="10" width="180" height="180" fill="red"

serif:id="background"

inkscape:label="bg-rect" />

</svg>

viewBox="0 0 200 200">

</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.

Attribute with the local name “xmlns:svg” is not serializable as XML 1.0.

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:svg violates these rules.
Serialization issues: If a browser parses the HTML and then re-serializes it (e.g., via innerHTML), the xmlns:svg attribute 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" alongside xmlns="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 the xmlns:svg attribute.
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, even xmlns is optional since the HTML parser infers the namespace automatically).

Examples

Incorrect: redundant prefixed namespace declaration

</svg>

The xmlns:svg attribute triggers the validation error because it is not serializable in HTML.

Correct: standard namespace only

</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>

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).

Attribute “xmlns:cc” not allowed here.

The xmlns:cc attribute declares the Creative Commons namespace used in SVG metadata, and HTML doesn't allow prefixed namespace declarations on <svg> or any other element.

Files saved by Inkscape often have xmlns:cc="http://creativecommons.org/ns#" on the root <svg> element. The prefix is for the Creative Commons terms in the file's RDF metadata. <cc:Work> wraps the description of the drawing, and if you pick a license under Document Properties, <cc:license> records it. In a standalone .svg file, which is XML, the declaration is valid. The error shows up when that markup ends up inside an HTML page, pasted by hand or inlined by a template or build step.

The HTML parser doesn't process namespace declarations, so xmlns:cc stays a plain attribute with a colon in its name. The validator rejects it on <svg>, and on <html> or <div> too. On <svg> it accepts just two namespace attributes, xmlns and xmlns:xlink. Inkscape exports usually put xmlns:cc next to xmlns:dc, xmlns:rdf, xmlns:sodipodi and xmlns:inkscape, and each of those gets its own message.

Delete xmlns:cc from the <svg> tag, and delete the <metadata> block with it. The cc: elements in that block break for the same parser reason. <cc:Work> becomes an SVG element whose name happens to contain a colon, and the validator reports cc:work and cc:license as completely-unknown elements in SVG content. None of the metadata is drawn, so the image doesn't change.

That block may be the only place the file states its license. If the license matters, keep the original .svg, metadata and all, in your source files, and show the license where readers can see it, such as in a caption under the image.

To stop the declaration from coming back, optimize the SVG before it gets inlined. SVGO's default preset runs removeEditorsNSData, which removes the Creative Commons namespace along with the Inkscape and Sodipodi ones, and removeMetadata, which removes the <metadata> block.

Invalid example

xmlns:cc="http://creativecommons.org/ns#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

width="120" height="120" viewBox="0 0 24 24">

<rdf:RDF>

<cc:Work rdf:about="">

<cc:license rdf:resource="https://creativecommons.org/licenses/by/4.0/" />

</cc:Work>

</rdf:RDF>

</metadata>

</svg>

Valid example

<title>Checkmark</title>

</svg>

Icon licensed under <a href="https://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>.

</figcaption>

</figure>

Attribute “xmlns:dc” not allowed here.

Attribute “xmlns:inkscape” not allowed here.

The xmlns:inkscape attribute declares the namespace Inkscape uses for its own editor data, and HTML doesn't allow prefixed namespace declarations on <svg> or any other element.

Inkscape's default file format, Inkscape SVG, puts xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" on the root <svg> element. The prefix marks attributes that only Inkscape reads: inkscape:version records the release that saved the file, and inkscape:groupmode="layer" with an inkscape:label turns a <g> into a named layer. Inkscape 0.92 also writes inkscape:connector-curvature="0" on paths, and inkscape:export-filename remembers where the last PNG export went. Browsers ignore all of them, so the image looks the same without them.

In an HTML page the declaration does nothing. The HTML parser doesn't handle namespace prefixes, so xmlns:inkscape is a plain attribute with a colon in its name, and the validator reports it on any element that carries it. Each inkscape: attribute gets its own message as well, such as Attribute "inkscape:version" not allowed on element "svg" at this point. Inkscape SVG files usually declare xmlns:sodipodi next to it, for attributes like sodipodi:docname, and the validator reports that declaration separately.

Delete xmlns:inkscape and every attribute that starts with inkscape:. Removing only the declaration leaves the attribute errors behind. The layers turn into plain groups and lose their labels, so if a stylesheet or script needs to find one, use the group's id (Inkscape assigns ids like layer1) or add a class.

When you clean up a standalone .svg file, remove the declaration and the attributes together. Delete xmlns:inkscape but leave a single inkscape:label behind, and the file stops being well-formed XML, because it uses a prefix it never declares. Browsers then refuse to display it (Firefox reports an "unbound prefix").

To get a copy without the Inkscape markup, use File > Save a Copy and choose Optimized SVG or Plain SVG. Optimized SVG runs Scour, which strips editor data unless you check its "Keep editor data" option. Plain SVG drops the inkscape: and sodipodi: markup but still writes xmlns:svg, which the validator also rejects.

Keep the Inkscape SVG as the file you edit. A copy without the editor data reopens without its layers, and shapes drawn with the star tool come back as plain paths. If a build step inlines your SVGs, SVGO removes the same markup with removeEditorsNSData, which is part of its default preset.

Invalid example

xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

inkscape:version="1.3.2"

width="24" height="24" viewBox="0 0 24 24">

</g>

</svg>

Valid example

width="24" height="24" viewBox="0 0 24 24">

</g>

</svg>

Attribute “xmlns:o” not allowed here.

xmlns
svg

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:o attributes 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, and xmlns: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>

<head>

<title>Company Report</title>

</head>

<body xmlns: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>

<p class="MsoNormal">Revenue increased by 15% this quarter.<o:p></o:p></p>

<p class="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>

<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

<p class="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.

Attribute “xmlns:rdf” not allowed here.

The xmlns:rdf attribute declares the RDF namespace that SVG editors use for the metadata block in a drawing, and HTML doesn't allow prefixed namespace declarations on <svg> or any other element.

Inkscape SVG files, such as those saved by Inkscape 0.92, declare xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" on the root <svg> element, next to xmlns:dc and xmlns:cc. RDF (Resource Description Framework) is the W3C model for describing things as statements, and the rdf: namespace holds its core terms. Inkscape uses them to build the <metadata> block. <rdf:RDF> wraps the description, rdf:about="" says it is about this file, and rdf:resource gives a property a URI as its value, such as the Dublin Core type StillImage. The title and format are Dublin Core (dc:) terms, and the license is a Creative Commons (cc:) one. In a standalone .svg file, which is XML, all of this is valid.

Inline the file in an HTML page and the block stops being RDF. The HTML parser doesn't process namespace declarations, so xmlns:rdf is a plain attribute with a colon in its name, and the validator reports it on <svg>, on <html> and on any other element. The elements lose their namespace too. <rdf:RDF> becomes an SVG element named rdf:rdf, which the validator reports as a completely-unknown element, along with every element nested in it.

Delete xmlns:rdf together with the <metadata> block. Removing only the declaration leaves all those unknown-element errors in place. Nothing in the block is drawn, so the image doesn't change. The same export usually declares xmlns:dc, xmlns:cc, xmlns:sodipodi and xmlns:inkscape too. Each gets its own message, and they all go in the same cleanup.

If the page needs machine-readable facts about the image, such as who made it or what license it has, describe it in JSON-LD instead. A <script type="application/ld+json"> block with a schema.org ImageObject can hold creator and license, and its contentUrl points at the image file, for example the original .svg with its metadata intact. Google's image metadata documentation asks for contentUrl plus at least one of creator, creditText, copyrightNotice or license.

On <html>, xmlns:rdf is a leftover from XHTML+RDFa 1.0, which declared prefixes with xmlns:. RDFa 1.1 uses the prefix attribute instead, and rdf is one of its predefined prefixes, so you can delete the declaration without adding anything in its place.

To keep the declaration out of inlined SVGs, run them through SVGO first. Its default preset includes removeEditorsNSData, whose list of editor namespaces contains RDF, and removeMetadata, which drops the <metadata> block.

Invalid example

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:dc="http://purl.org/dc/elements/1.1/"

width="240" height="160" viewBox="0 0 240 160">

<rdf:RDF>

<rdf:Description rdf:about="">

<dc:title>Route map</dc:title>

<dc:creator>Jane Doe</dc:creator>

<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" />

</rdf:Description>

</rdf:RDF>

</metadata>

</svg>

Valid example

<title>Route map</title>

</svg>

{

"@context": "https://schema.org",

"@type": "ImageObject",

"contentUrl": "https://example.com/images/route-map.svg",

"name": "Route map",

"creator": { "@type": "Person", "name": "Jane Doe" },

"license": "https://creativecommons.org/licenses/by/4.0/"

}

</script>

Attribute “xmlns:serif” not allowed here.

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

xmlns:serif="https://www.serif.com/"

viewBox="0 0 100 100">

</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

viewBox="0 0 100 100">

</svg>

Incorrect — multiple proprietary namespaces

Design tools sometimes add several custom namespaces at once:

xmlns:serif="https://www.serif.com/"

xmlns:xlink="http://www.w3.org/1999/xlink"

viewBox="0 0 200 200">

</g>

</svg>

Correct — only standard namespaces retained

viewBox="0 0 200 200">

<g>

</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.

Attribute “xmlns:sketch” not allowed here.

The xmlns:sketch attribute declares the namespace the Sketch design app used for its layer data, and HTML doesn't allow prefixed namespace declarations on <svg> or any other element.

Sketch is a macOS design app from Bohemian Coding. Until version 3.6, it put xmlns:sketch="http://www.bohemiancoding.com/sketch/ns" on the root <svg> of every SVG it exported. The prefix is there for the sketch:type attributes, which record what each element was in the Sketch document: MSPage on the page group, MSArtboardGroup on the artboard, MSLayerGroup on a group of layers and MSShapeGroup on each shape. Sketch 3.6, released in March 2016, dropped these prefixes to make its SVG exports smaller. An SVG that still carries them was exported before then and ended up in a page or template later.

The HTML parser doesn't handle namespace prefixes, so xmlns:sketch is a plain attribute with a colon in its name. The validator reports it on any element that carries it, whether that's <svg> or a <div>. Each sketch:type gets its own message too, such as Attribute "sketch:type" not allowed on element "path" at this point. Browsers ignore this markup, so removing it doesn't change how the icon looks.

Delete xmlns:sketch and every sketch:type attribute. Removing only the declaration leaves one error per sketch:type behind. Delete them together in a standalone .svg file too: if a sketch:type survives without its declaration, the file is no longer well-formed XML and browsers won't display it.

Sketch's export also copies the layer name into <title> and adds <desc>Created with Sketch.</desc>. Neither one is a validation error. In inline SVG, though, the browser uses <title> as the image's accessible name and <desc> as its description, so a screen reader can announce "Created with Sketch." Give the <title> a name that describes the icon, and delete the <desc>.

If a build step inlines your SVG files, SVGO removes the Sketch markup for you. Its default preset runs removeEditorsNSData, and http://www.bohemiancoding.com/sketch/ns is on that plugin's list of editor namespaces, so it deletes the declaration and every sketch: attribute. The preset's removeDesc plugin deletes a <desc> that starts with "Created with".

Invalid example

xmlns="http://www.w3.org/2000/svg"

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:sketch="http://www.bohemiancoding.com/sketch/ns">

<title>check</title>

<desc>Created with Sketch.</desc>

</g>

</svg>

Valid example

xmlns="http://www.w3.org/2000/svg"

xmlns:xlink="http://www.w3.org/1999/xlink">

<title>Checkmark</title>

</g>

</svg>

Attribute “xmlns:sodipodi” not allowed here.

The xmlns:sodipodi attribute declares the namespace for editor data that Inkscape inherited from Sodipodi, and HTML doesn't allow prefixed namespace declarations on <svg> or any other element.

Sodipodi was a vector drawing program written mainly by Lauris Kaplinski, and SVG was its native file format. In 2003 a group of its developers forked it to start Inkscape. Sodipodi itself stopped at version 0.34, released in February 2004. Inkscape kept the sodipodi: prefix for the features it inherited, so files saved by current versions still declare xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" on the root <svg>. The URI is only a name for the namespace. Nothing downloads that DTD.

The prefix marks editor state. <sodipodi:namedview>, a child of the root <svg>, keeps the document's view settings: page and border colors, the grid, zoom and window position, the current layer, and any guide lines as <sodipodi:guide> children. On the root element, sodipodi:docname records the file name the drawing was last saved under.

Shapes and text carry their own sodipodi: attributes. sodipodi:nodetypes on a path has one letter per node (c for cusp, s for smooth, z for symmetric, a for auto-smooth), which the node tool reads to decide how a node's handles move. sodipodi:type marks a path drawn with a shape tool, such as star, arc or spiral, and attributes like sodipodi:sides and sodipodi:r1 keep the shape's parameters so Inkscape can bring its handles back. Lines of text get sodipodi:role="line" on their <tspan>. Browsers ignore all of it, and a star is drawn from the path's d attribute like any other path.

The HTML parser doesn't link prefixes to declarations. To it, xmlns:sodipodi is one attribute with a colon in its name and sodipodi:docname is another, and nothing connects the two. Delete only the declaration and every other sodipodi: name still fails on its own. The invalid example below gets 13 errors, and only one of them is about xmlns:sodipodi. The other 12 come from the sodipodi: attributes, such as Attribute "sodipodi:type" not allowed on element "path" at this point., and from <sodipodi:namedview> and <sodipodi:guide>, which the validator reports as completely-unknown elements in SVG content.

Delete xmlns:sodipodi, the <sodipodi:namedview> element with everything inside it, and every attribute that starts with sodipodi:. The image looks the same afterwards. Only Inkscape notices: the guides, grid and page settings are gone, and stars and spirals reopen as plain paths. Keep the original file for editing and put a cleaned copy in the page.

The same Inkscape file usually declares xmlns:inkscape, xmlns:rdf, xmlns:cc and xmlns:dc too, and each gets its own message. SVGO's removeEditorsNSData plugin, part of its default preset, removes the Sodipodi declaration and every sodipodi: element and attribute, and does the same for those four namespaces. If the whole file was pasted in, its <?xml version="1.0"?> line comes along too, and the validator reports it as an XML processing instruction.

Invalid example

xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

sodipodi:docname="star.svg"

width="24" height="24" viewBox="0 0 24 24">

<sodipodi:namedview pagecolor="#ffffff" showgrid="false">

<sodipodi:guide position="12,12" orientation="1,0" />

</sodipodi:namedview>

<path sodipodi:type="star" sodipodi:sides="5"

sodipodi:cx="12" sodipodi:cy="12" sodipodi:r1="10" sodipodi:r2="4"

sodipodi:arg1="-1.5708" sodipodi:arg2="-0.9425"

d="M12,2 14.35,8.76 21.51,8.91 15.8,13.24 17.88,20.09 12,16 6.12,20.09 8.2,13.24 2.49,8.91 9.65,8.76Z"

fill="currentColor" />

</svg>

Valid example

width="24" height="24" viewBox="0 0 24 24">

<path d="M12,2 14.35,8.76 21.51,8.91 15.8,13.24 17.88,20.09 12,16 6.12,20.09 8.2,13.24 2.49,8.91 9.65,8.76Z"

fill="currentColor" />

</svg>

Attribute “xmlns:svg” not allowed here.

svg
xmlns

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 the xmlns:svg attribute.
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., use href instead of xlink:href).

Examples

Incorrect: using `xmlns:svg` on an SVG element

The xmlns:svg attribute triggers the validation error:

</svg>

Correct: removing the prefixed namespace

Remove xmlns:svg and keep only the standard attributes:

</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:

</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):

</svg>

After (cleaned up for HTML5):

</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.

Bad value “” for attribute “aria-labelledby” on element “svg”: An IDREFS value must contain at least one non-whitespace character.

The aria-labelledby attribute is an IDREFS attribute, meaning its value must be a space-separated list of one or more id values that exist in the document. These referenced elements collectively provide the accessible name for the element. When the value is an empty string ("") or contains only whitespace, there are no valid ID references, which violates the IDREFS requirement defined in the WAI-ARIA and HTML specifications.

This issue commonly appears when templating systems or JavaScript frameworks conditionally set aria-labelledby but output an empty string when no label ID is available. It also occurs when developers add the attribute as a placeholder with the intention of filling it in later but forget to do so.

Why this matters

An empty aria-labelledby is problematic for several reasons:

Accessibility: Screen readers rely on aria-labelledby to announce the accessible name of an element. An empty value can cause unpredictable behavior — some screen readers may ignore the SVG entirely, while others may fall back to reading unhelpful content or nothing at all. This leaves users who depend on assistive technology without a meaningful description of the graphic.
Standards compliance: The W3C validator flags this as an error because the HTML specification requires IDREFS attributes to contain at least one non-whitespace character. Shipping invalid HTML can signal broader quality issues and may cause problems in strict parsing environments.
Maintainability: An empty aria-labelledby is ambiguous. It's unclear whether the developer intended the SVG to be decorative, forgot to add a reference, or encountered a bug in their templating logic.

How to fix it

Choose the approach that matches your intent:

Reference a labeling element by ID: If the SVG conveys meaning, add a <title> element (or another visible text element) inside or near the SVG with a unique id, then set aria-labelledby to that id. IDs are case-sensitive, so ensure an exact match.
Use aria-label instead: If you want to provide an accessible name directly as a text string without needing a separate element, replace aria-labelledby with aria-label.
Remove the attribute: If the SVG already has an accessible name through other means (such as visible adjacent text or a <title> child that doesn't need explicit referencing), simply remove the empty aria-labelledby.
Mark as decorative: If the SVG is purely decorative and adds no information, remove aria-labelledby and add aria-hidden="true" so assistive technology skips it entirely.

When generating aria-labelledby dynamically, ensure your code omits the attribute entirely rather than outputting an empty value when no label ID is available.

Examples

❌ Empty `aria-labelledby` (triggers the error)

</svg>

The empty string is not a valid IDREFS value, so the validator reports an error.

✅ Reference a `<title>` element by ID

<title id="star-title">Favorite</title>

</svg>

The aria-labelledby points to the <title> element's id, giving the SVG a clear accessible name of "Favorite."

✅ Use `aria-label` with a text string

</svg>

When you don't need to reference another element, aria-label provides the accessible name directly as an attribute value.

✅ Reference multiple labeling elements

<title id="star-title">Favorite</title>

<desc id="star-desc">A five-pointed star icon</desc>

</svg>

The aria-labelledby value can include multiple space-separated IDs. The accessible name is constructed by concatenating the text content of the referenced elements in order.

✅ Decorative SVG (no accessible name needed)

</svg>

For purely decorative graphics, aria-hidden="true" removes the element from the accessibility tree. Adding focusable="false" prevents the SVG from receiving keyboard focus in older versions of Internet Explorer and Edge.

Bad value “” for the attribute “xmlns” (only “http://www.w3.org/2000/svg” permitted here).

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 xmlns on 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 .svg files).
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 xmlns value with "http://www.w3.org/2000/svg".
Remove the attribute entirely: Since xmlns is 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>

Incorrect: wrong namespace value

Any value other than the correct SVG namespace will also trigger this error:

</svg>

Fix: use the correct namespace

Set xmlns to the only permitted value:

</svg>

Fix: remove the `xmlns` attribute

In an HTML5 document, you can omit xmlns altogether since the parser handles the namespace automatically:

</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.

Bad value “https://www.w3.org/2000/svg” for the attribute “xmlns” (only “http://www.w3.org/2000/svg” permitted here).

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>

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>

✅ 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>

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.

Bad value “inline-block” for attribute “display” on element “svg”.

Bad value “none” for attribute “text-anchor” on element “g”.

This W3C validation error has two distinct problems combined into one message. First, the value "none" is not a recognized value for the text-anchor attribute — the only accepted values are start, middle, and end. Second, the <g> element is a generic container used to group SVG shapes together and does not support the text-anchor attribute directly.

The text-anchor attribute controls how text is aligned relative to its anchor point (the x coordinate). A value of start aligns the beginning of the text to the anchor, middle centers the text on the anchor, and end aligns the end of the text to the anchor. There is no "none" value because text always needs an alignment — start is the default if the attribute is omitted.

Why this is a problem

Invalid markup: Using an unrecognized value like "none" means browsers must guess the intended behavior, which can lead to inconsistent rendering across different environments.
Wrong element: The <g> element does not directly render text, so text-anchor has no meaningful effect on it. While CSS inheritance might cause child text elements to pick up styles from a parent <g>, the text-anchor presentation attribute is only valid on elements that actually render text content.
Standards compliance: The SVG specification explicitly defines which elements accept text-anchor and which values are allowed. Violating this produces validation errors and may cause issues with SVG processing tools.

How to fix it

Remove the attribute from the <g> element and apply it to the appropriate text element inside the group.
Replace "none" with a valid value: start, middle, or end. If you want the default behavior (left-aligned for LTR text), simply omit the attribute entirely, as start is the default.
If you need to set text-anchor for multiple text elements inside a group, use CSS instead of the presentation attribute.

Examples

❌ Invalid: `"none"` on a `<g>` element

<text x="100" y="100">Hello</text>

</g>

</svg>

✅ Fixed: valid value on the `<text>` element

<text x="100" y="100" text-anchor="middle">Hello</text>

</svg>

✅ Fixed: attribute removed entirely (uses default `start`)

<g>

<text x="100" y="100">Hello</text>

</g>

</svg>

✅ Using CSS to style text inside a group

If you want all text elements within a group to share the same alignment, apply the style via CSS rather than a presentation attribute on <g>:

<style>

.centered-text text {

text-anchor: middle;

}

</style>

<text x="100" y="50">First line</text>

<text x="100" y="100">Second line</text>

</g>

</svg>

✅ Valid use on other text-related elements

The text-anchor attribute can also be applied to <tspan> and <textPath>:

Start-aligned

<tspan x="150" dy="30" text-anchor="end">End-aligned span</tspan>

</text>

</svg>

Bad value X for attribute “id” on element “pattern”: Not a valid XML 1.0 name.

The <pattern> element lives inside <svg>, and SVG is an XML-based language. Unlike regular HTML — where id values follow relatively relaxed rules — SVG content must comply with XML 1.0 naming conventions. This means id values have stricter character and formatting requirements than you might be used to in plain HTML.

XML 1.0 Name Rules

An XML 1.0 name (used for id attributes in SVG) must follow these rules:

First character must be a letter (A–Z, a–z) or an underscore (_).
Subsequent characters can be letters, digits (0–9), hyphens (-), underscores (_), or periods (.).
Spaces and special characters like !, @, #, $, %, (, ), etc. are not allowed anywhere in the name.

Common mistakes that trigger this error include starting an id with a digit (e.g., 1pattern), a hyphen (e.g., -myPattern), or a period (e.g., .dotPattern), or including characters like spaces or colons.

Why This Matters

Standards compliance: SVG is parsed as XML in many contexts. An invalid XML name can cause parsing errors or unexpected behavior, especially when SVG is served with an XML MIME type or embedded in XHTML.
Functionality: The <pattern> element's id is typically referenced via url(#id) in fill or stroke attributes. An invalid id may cause the pattern reference to silently fail, leaving elements unfilled or invisible.
Cross-browser consistency: While some browsers are lenient with invalid XML names, others are not. Using valid names ensures consistent rendering across all browsers and environments.

How to Fix

Rename the id value so it starts with a letter or underscore and contains only valid characters. If you reference this id elsewhere (e.g., in fill="url(#...)" or in CSS), update those references to match.

Examples

❌ Invalid: `id` starts with a digit

<defs>

</pattern>

</defs>

</svg>

❌ Invalid: `id` starts with a hyphen

<defs>

</pattern>

</defs>

</svg>

❌ Invalid: `id` contains special characters

<defs>

</pattern>

</defs>

</svg>

✅ Valid: `id` starts with a letter

<defs>

</pattern>

</defs>

</svg>

✅ Valid: `id` starts with an underscore

<defs>

</pattern>

</defs>

</svg>

✅ Valid: Using letters, digits, hyphens, and underscores

<defs>

</pattern>

</defs>

</svg>

Note that this same XML 1.0 naming rule applies to id attributes on all SVG elements — not just <pattern>. If you see similar errors on elements like <linearGradient>, <clipPath>, or <filter>, the same fix applies: ensure the id starts with a letter or underscore and uses only valid characters.

Bad value X for attribute “src” on element “img”: Illegal character after “ta:”. “<” is not allowed.

Bad value X for attribute “src” on element “img”: Illegal character after “ta:”. Space is not allowed.

Bad value X for attribute “version” on element “svg”.

svg
version

Bad value X for the attribute “xmlns:link” (only “http://www.w3.org/1999/xlink” permitted here).

Bad value X for the attribute “xmlns” (only “http://www.w3.org/2000/svg” permitted here).

Saw “<?”. Probable cause: Attempt to use an XML processing instruction in HTML. (XML processing instructions are not supported in HTML.)

XML processing instructions are a feature of XML, not HTML. They begin with <? and end with ?>, and are used in XML documents to carry instructions for applications processing the document. The most common example is the XML declaration: <?xml version="1.0" encoding="UTF-8"?>. While these are perfectly valid in XML, the HTML parser does not recognize them. When the parser encounters <?, it doesn't know how to handle it and treats it as a bogus comment, which leads to unexpected behavior and this validation error.

This matters for several reasons. First, standards compliance — HTML5 has a clearly defined parsing algorithm, and processing instructions are not part of it. Second, browser behavior becomes unpredictable — different browsers may handle the unexpected <? content differently, potentially exposing raw code or breaking your layout. Third, if server-side code like PHP leaks into the output, it can expose sensitive logic or configuration details to end users.

There are three common causes of this error:

1. Inlining SVG files with their XML declaration. When you copy the contents of an .svg file and paste it directly into HTML, the file often starts with an XML declaration and possibly a <?xml-stylesheet?> processing instruction. These must be removed — only the <svg> element and its children should be included.

2. Unprocessed server-side code. Languages like PHP use <?php ... ?> (or the short tag <? ... ?>) syntax. If the server isn't configured to process PHP files, or if a .html file contains PHP code without being routed through the PHP interpreter, the raw <?php tags end up in the HTML sent to the browser.

3. Copy-pasting XML content. Other XML-based formats (like RSS feeds, XHTML fragments, or MathML with XML declarations) may include processing instructions that aren't valid in HTML.

How to Fix It

For inline SVGs: Open the SVG file in a text editor and copy only the <svg>...</svg> element. Remove the <?xml ...?> declaration and any other processing instructions that precede the <svg> tag.
For PHP or other server-side code: Ensure your server is properly configured to process the files. Check that the file extension matches what the server expects (e.g., .php for PHP files). Verify that the server-side language is installed and running.
For other XML content: Strip out any <?...?> processing instructions before embedding the content in HTML.

Examples

❌ Inline SVG with XML declaration

<body>

<?xml version="1.0" encoding="UTF-8"?>

</svg>

</body>

The <?xml version="1.0" encoding="UTF-8"?> line triggers the error.

✅ Inline SVG without XML declaration

<body>

</svg>

</body>

❌ Unprocessed PHP code in HTML output

<body>

<h1>Welcome</h1>

</body>

If the server doesn't process the PHP, the raw <?php ... ?> ends up in the HTML and triggers this error.

✅ Properly processed output (or static HTML equivalent)

<body>

<h1>Welcome</h1>

<p>Hello, World!</p>

</body>

❌ SVG with an XML stylesheet processing instruction

<body>

<?xml-stylesheet type="text/css" href="style.css"?>

</svg>

</body>

✅ SVG without the processing instruction

<body>

</svg>

</body>

In HTML, use standard <link> or <style> elements in the <head> for stylesheets instead of XML processing instructions.

Text not allowed in element “svg” in this context.

HTML Guides for svg

HTML Examples

❌ Invalid: editor-specific namespaces in inline SVG

✅ Valid: clean inline SVG without editor namespaces

How to Fix It

Examples

❌ Invalid: SVG with xmlns:serif attribute

✅ Valid: SVG with proprietary attributes removed

Handling Multiple Proprietary Namespaces

Why this matters

How to fix it

Examples

Incorrect: redundant prefixed namespace declaration

Correct: standard namespace only

Correct: inline SVG in HTML5 without any namespace attribute

Invalid example

Valid example

Invalid Example

Valid Example

Invalid example

Valid example

Why This Happens

Why It Matters

How to Fix It

Examples

❌ Invalid: Office namespace declarations on elements

✅ Valid: Clean HTML without Office namespaces

❌ Invalid: Namespace on a div element

✅ Valid: Clean version

Invalid example

Valid example

Examples

Incorrect — custom namespace attribute present

Correct — custom namespace and prefixed attributes removed

Incorrect — multiple proprietary namespaces

Correct — only standard namespaces retained

Invalid example

Valid example

Invalid example

Valid example

Why it matters

How to fix it

Examples

Incorrect: using xmlns:svg on an SVG element

Correct: removing the prefixed namespace

Also correct: minimal inline SVG in HTML5

Cleaning up multiple unnecessary namespaces

Why this matters

How to fix it

Examples

❌ Empty aria-labelledby (triggers the error)

✅ Reference a <title> element by ID

✅ Use aria-label with a text string

✅ Reference multiple labeling elements

✅ Decorative SVG (no accessible name needed)

Examples

Incorrect: empty xmlns attribute

Incorrect: wrong namespace value

Fix: use the correct namespace

Fix: remove the xmlns attribute

Note on inline SVG from external sources

How to Fix It

Examples

❌ Incorrect: Using https in the namespace URI

✅ Correct: Using http in the namespace URI

✅ Correct: Inline SVG in HTML without xmlns

Invalid example

Valid example

Why this is a problem

How to fix it

Examples

❌ Invalid: "none" on a <g> element

✅ Fixed: valid value on the <text> element

✅ Fixed: attribute removed entirely (uses default start)

✅ Using CSS to style text inside a group

✅ Valid use on other text-related elements

XML 1.0 Name Rules

Why This Matters

How to Fix

Examples

❌ Invalid: SVG with `xmlns:serif` attribute

❌ Invalid: Namespace on a `div` element

Incorrect: using `xmlns:svg` on an SVG element

❌ Empty `aria-labelledby` (triggers the error)

✅ Reference a `<title>` element by ID

✅ Use `aria-label` with a text string

Incorrect: empty `xmlns` attribute

Fix: remove the `xmlns` attribute

❌ Incorrect: Using `https` in the namespace URI

✅ Correct: Using `http` in the namespace URI

✅ Correct: Inline SVG in HTML without `xmlns`

❌ Invalid: `"none"` on a `<g>` element

✅ Fixed: valid value on the `<text>` element

✅ Fixed: attribute removed entirely (uses default `start`)

❌ Invalid: `id` starts with a digit

❌ Invalid: `id` starts with a hyphen

❌ Invalid: `id` contains special characters

✅ Valid: `id` starts with a letter

✅ Valid: `id` starts with an underscore

Invalid example: extra `>` in the start tag

Valid example: label in a `title` element

Validate at scale.
Ship accessible websites, faster.