SVG validation guide
A file can be valid XML and still render badly, contain risky markup, or lack an accessible name. Check each layer separately so you know what needs fixing.
To validate an SVG, first check that it is well-formed XML with an <svg> root. Then preview it, inspect the viewBox and internal references, scan for unsafe markup, and review accessibility. One green check cannot prove all five.
SVG is an XML-based graphics language. The SVG 2 conformance rules describe a stand-alone SVG file as well-formed XML with an svg root. That is the starting point, not the whole review.
The W3C also notes that an image/svg+xml processor expects well-formed XML but cannot assume the document is valid against a particular DTD or schema. In practice, “validate SVG” can refer to several different checks.
| Check | What it finds | What it does not prove |
|---|---|---|
| XML parsing | Broken tags, quotes, entities, and nesting | Correct appearance or safe content |
| Browser preview | Blank output, clipping, and obvious rendering changes | Consistent output in every app |
| Safety review | Scripts, event handlers, and unsafe links | A complete upload security policy |
| Accessibility review | Missing names, roles, ARIA references, and duplicate IDs | Full WCAG conformance in its final page context |
<svg> root in the SVG namespace, normally written as xmlns="http://www.w3.org/2000/svg".viewBox, width, and height. The SVG 2 viewBox definition requires four numbers, and zero width or height disables rendering.Check the line named in the error. Look for a missing closing tag, mismatched quote, bare ampersand, duplicate attribute, or content pasted outside the root element. Fix one syntax error at a time because the first error can hide the next one.
Check for a missing or malformed viewBox, zero width or height, artwork positioned outside the canvas, white artwork on a white background, or a broken url(#id) reference.
External fonts, CSS, linked images, filters, masks, and editor-specific metadata do not travel equally well. Keep the original, clean a copy, and compare the result in the browser and the destination app.
XML validity does not make active content harmless. Remove scripts, inline event handlers, unsafe URLs, and unsupported elements. If your product accepts user uploads, enforce a server-side allowlist too.
An SVG can parse without a viewBox, but responsive scaling becomes harder and the artwork may be clipped or sized unexpectedly. The attribute contains min-x, min-y, width, and height. Use the SVG viewBox editor to inspect or fit the canvas around existing artwork.
A parser cannot decide whether an image is meaningful in its page context. W3C guidance recommends an accessible name for SVG content that people need to understand, using a direct child <title>, aria-label, or aria-labelledby. Decorative graphics should be hidden from assistive technology when appropriate.
Start by parsing the SVG as XML and confirming that it has an svg root. Then check its viewBox and dimensions, preview the artwork, review scripts and links, and test accessibility in the final page context.
Common causes include an unclosed tag, a mismatched quote, a bare ampersand, a duplicate attribute, or content outside the root svg element. Fix the first reported syntax error, then parse the file again.
Yes. Valid XML can still have a zero-size or incorrect viewBox, artwork outside the canvas, broken internal references, missing external assets, or colors that disappear against the background.
Not necessarily. XML validity does not remove scripts, event handlers, unsafe URLs, or remote references. Clean unknown files and use a server-side allowlist when accepting public uploads.
No. Automated checks can find missing names, broken ARIA references, duplicate IDs, and possible focus targets. Meaning, contrast, keyboard behavior, and assistive technology support still need review in context.