SVG viewer & validator

How it works

The file is parsed with the browser's own XML parser and inspected statically, in your tab — nothing is uploaded. The document card reads the vital signs off the root element: file size, element count, the declared width and height, the viewBox, and how many ids the document defines. The checks then walk the whole tree for the failure modes that actually bite — a missing namespace, no viewBox, duplicate ids, scripts and event handlers, embedded rasters, external references, foreignObject, and a missing accessible name. Each finding states the consequence, because "invalid" is less useful than "renders blank in an img tag".

The preview alongside is a real render of your file, with one precaution: scripts, event-handler attributes and foreignObject are stripped from the rendered copy only, so a stray onload= in a file someone handed you does not run just because you wanted to look at it. The source you export or carry into other tools is untouched.

What the checks look for

Identity and geometry first. A root without xmlns="http://www.w3.org/2000/svg" renders inline in HTML but comes up blank as a standalone file or in an <img> — the classic "works on my page" bug. Duplicate ids make references resolve to whichever element comes first, so a gradient or clip path can silently point at the wrong target. A file with no viewBox and no complete width/height has no intrinsic size at all, and browsers fall back to 300 × 150; a file with dimensions but no viewBox will not scale. Physical units (pt, mm) in the dimensions are flagged too — they come from print exports and turn into surprising pixel sizes on screen.

Then content that fails quietly elsewhere. <script> and on* handlers run when a file is inlined but are stripped by sanitizers and ignored in <img>. An embedded <image> is a bitmap in vector clothing and usually carries most of the file's weight. Resources referenced by URL never load in <img>, CSS backgrounds or sandboxes. <style> blocks bring document-global class names — two inlined icons defining .st0 restyle each other. Live <text> depends on the viewer's installed fonts. Finally the accessibility check: a file with no first-child <title>, no aria-label and no hidden marker gives a screen reader nothing to announce — the accessible icons guide covers the fix in full.

Validating markup that will not parse

The checks need a parsed document, and a file with mismatched tags or a bare ampersand never gets that far. The validation box exists for exactly that case: paste anything into it — broken markup included — and it reports the XML parser's own error, condensed to the line that carries the position, so you know it is line 3, column 41 rather than "somewhere". The usual culprits are an unclosed element, an attribute missing its closing quote, a raw & that should be &, or two root elements from a careless paste. The moment the markup parses, it is loaded into the viewer above and the full checks run on it.

When to use it

When a file renders in one place and not another — the answer is usually in the first three checks. Before committing third-party icons to a repository, to see what you are actually taking on: an icon from a random download site can carry scripts, tracking references or a 200 KB embedded bitmap, and this page lists all three in one pass. And as a pre-flight for files heading into an <img>, a favicon or an email, which are exactly the contexts where scripts, external fonts and foreignObject go quietly blank.

Viewer or editor?

This page is deliberately read-only: it renders, measures and reports, and changes nothing — the point is a trustworthy diagnosis. When a finding needs acting on, each one names the tool that fixes it: a missing or wrong viewBox is the resize tool's job, over-precise coordinates and empty groups are the optimizer's, and anything structural — deleting a stray element, renaming ids, editing shapes — is a one-click hop into the editor, which takes the open document with it. Unreadable markup is a job for the formatter first; you cannot inspect what you cannot read.

Common problems

• Every check passes and the file still doesn't show. The checks are static — they cannot see geometry drawn outside the viewBox. Open the file in the Resize tool and rebuild the viewBox from the measured bounds.
• The validator accepts what another tool rejects. Well-formed XML with an svg root is the bar here; a stricter consumer may still object to unknown elements it refuses to ignore. The checks list is the practical subset.
• Line numbers in parse errors don't match your editor. They count from the start of the pasted markup — a stripped XML declaration or leading blank line shifts them by one.
• "All clear" but the file is still enormous. The checks flag causes, not size itself — a clean file can still carry fifteen decimals on every coordinate. The over-precision note only fires past a threshold; the optimizer's before/after numbers are the direct answer.