Why Is My SVG Not Showing? (The Complete Diagnostic)

An SVG that doesn’t show gives you nothing to go on – no error, no broken-image icon sometimes, just absence. But invisibility has a finite cause list, and one test splits it in half immediately. Start there.

The splitting test

Open the SVG file directly in a browser tab (drag the file in, or paste its code into a live editor).

• Renders fine? → The file is good. Your problem is the embedding – how the page or platform loads it. Go to section B.
• Blank here too? → The file itself is broken or self-hiding. Section A.

Thirty seconds, half the suspects eliminated.

Section A: The file is the problem

A1. Missing xmlns. An SVG used inline in HTML doesn’t need a namespace; the same markup saved as a file does. Without xmlns="http://www.w3.org/2000/svg" on the root element, browsers render standalone SVGs blank. This is the classic “works on my page, blank as a file” bug – add the attribute.

A2. Sizing collapse. No width/height and no viewBox → some contexts render it at 0×0 or collapse it entirely. Add a viewBox matching the artwork’s coordinates (the sizing model).

A3. Invisible styling. The file renders – white shapes on a white page. Or fills use currentColor/CSS classes that don’t resolve standalone, falling back to invisible or black. The editor’s checkered background exposes this instantly: shapes visible there but not on your page = color/context issue, not visibility issue.

A4. Broken markup. Truncated download, email-mangled quotes, or a renamed PNG wearing .svg. The editor shows parse failures; repairs are usually quick – the broken-file guide.

A5. Everything’s outside the viewBox. Valid file, valid shapes, drawn at coordinates the viewBox doesn’t show. Symptom: file “renders” as empty space of the right size. Inspect the viewBox against path coordinates (viewBox explained).

Section B: The embedding is the problem

B1. Wrong MIME type (the web classic). Servers must send Content-Type: image/svg+xml; sent as text/plain, browsers refuse to render it via <img>. Check DevTools → Network → the SVG’s response headers. Fix server config (most hosts handle it; misconfigured custom servers and some CDN setups don’t).

B2. Path and case. Logo.svg ≠ logo.svg on production Linux servers, while it works on your case-insensitive Mac/Windows dev machine. The DevTools Network tab shows the 404.

B3. CSS interference. Inline SVGs inherit page CSS: a global svg { display: none } from an icon system, a zero-height flex container, fill: white cascading in. DevTools → inspect the element → check computed size and styles.

B4. The <img> isolation rules. SVGs via <img> can’t run scripts, load external resources, or be styled by page CSS – an SVG depending on any of those shows partially or not at all. Inline it instead, or make the file self-contained.

Section C: The platform refuses SVG, full stop

Some destinations don’t render SVG by policy – it’s scriptable XML, hence a security surface:

• WordPress blocks SVG uploads by default (fix: a sanitizing plugin like Safe SVG, or upload PNG).
• Email clients (Gmail, Outlook) strip SVG – email is raster-only territory; send PNG at 2×.
• Social platforms, many marketplaces and CMSs – same story.

No file fix applies here; convert and move on.

The compressed version

File test → fails: fix xmlns/viewBox/markup. Passes: check MIME, path case, CSS. Platform blocks SVG by policy: ship PNG.

The full checklist with copy-paste fixes lives at the SVG not showing hub.