You asked a model for an SVG. The code looks right — tags, paths, colors, all plausible. You paste it into a file, open it in a browser, and get... a blank rectangle. No error, no warning, nothing.
If this happens to you regularly, it's not bad luck. SVG is XML, and XML is unforgiving in a way HTML never is. A browser reading HTML will patch over a missing quote or an unclosed tag and render what it can. A browser reading SVG does none of that: one syntax slip and the whole document is rejected — usually silently.
Language models generate SVG the way they generate everything else: token by token, plausibly. They pattern-match on millions of examples without running an XML validator or a geometry engine. So they fail on exactly the details a validator would have caught — and they fail in the same ways, over and over. Here are the eight defects behind almost every broken AI-generated SVG I've seen.
1. Missing xmlns attribute. The #1 killer. Without xmlns="http://www.w3.org/2000/svg" the browser treats the file as generic XML. It may render inline in an HTML page, then fail as a standalone file or inside an <img> tag — which makes it look like a caching bug. Models forget it constantly.
2. Missing or invented viewBox. No viewBox, and the browser has no idea which part of the coordinate system to show. Or the model writes viewBox="0 0 24 24" and then draws at x="150" — every shape lands off-canvas and you get an empty frame.
3. Shapes translated out of view. AI loves decorative transform="translate(350, 280)" guesswork. The markup is valid, the preview is blank, and nothing tells you the artwork is sitting just outside the frame.
4. A raw & in a label. SVG is strict XML. A label like Tom & Jerry with a bare unescaped & invalidates the entire document. One character, whole file dead.
5. NaN and Infinity coordinates. Models do arithmetic in public: d="M 10 10 L NaN 50" or a radius of Infinity. The path is syntactically present and renders as nothing.
6. Unclosed or misnested tags. Truncated output, a <g> that never closes, an attribute missing its quote. XML parsers are all-or-nothing — one structural slip and nothing renders at all.
7. Chat prose and code fences. "Sure! Here's your logo:" ... `` ``` svg ... "Let me know if you'd like adjustments!" Paste that into a file and you have prose, fences, and markup layered together. Browsers don't strip any of it for you.
8. Everything fill="none". The model styles each shape with fill="none" and forgets to add a stroke. The file parses, the shapes exist, the image is empty. This one fools people the most because the SVG technically "works".
Defects 1–6 kill the file outright at parse time. 7–8 are sneakier: the file renders, it just renders empty — worse to debug because there's no error message to search for.
Before fixing anything, figure out which defect you have:
xmlns. Missing? That's defect 1. viewBox against the largest coordinates in the file. Drawing at 400 but viewing 0–24? Defect 2 or 3.NaN, Infinity, or a bare & outside entities. Defects 4 and 5.fill="none" and no stroke? Defect 8.
Or skip the manual pass: paste the raw chat output — prose and fences and all — into SVG Repair. It extracts the real markup, repairs the XML, adds the missing xmlns and viewBox, zeroes out NaN coordinates, expands the canvas to include off-screen shapes, makes invisible shapes visible, and shows you an itemized report of every defect next to a before/after preview. It actually renders the repaired file and checks it paints a non-empty image before claiming success. Everything runs client-side — the file never leaves your browser.
Repairing is faster than regenerating, but the cheapest fix is an SVG that isn't broken. Four lines added to the prompt eliminate most defects:
0 0 512 512. Use no transforms." — kills defect 3.<script>, no CSS classes, no text — convert text to paths." — kills the surprise below.
Models occasionally emit <script> tags, onload handlers, or foreignObject blocks — sometimes because you asked for animation, sometimes out of nowhere. That matters beyond rendering: an SVG carrying scripts becomes a live XSS vector the moment someone opens it directly or inlines it into a page. If you're accepting SVGs from users, or embedding AI output into anything public, strip active content before it ships. The repair pipeline above strips it by default.
A repaired file is a working file, not a finished one. AI output carries redundant precision and empty groups that a proper SVG optimizer typically shaves 30–60%. Whole icon sets can be repaired and converted in batch. And when the geometry is almost right, a free browser-based SVG editor lets you fix it visually — select and move shapes, edit text, adjust fills and strokes — without installing anything or up the file anywhere.
The full write-up with more prompt examples is here: Why your AI-generated SVG doesn't render.