SVG Not Showing in Browser? 12 Fixes That Work in 30 Seconds
You have a clear vector icon that looks great in Figma or Illustrator. You place it into your webpage, refresh the browser, and see nothing. Just a blank space where the icon should be. Or worse, a small broken-image icon. Maybe the SVG appears, but it's the wrong size, or part of it is missing. It might display correctly in Chrome but vanish in Safari. This is one of the most frequent and confusing issues developers and designers face with SVGs. The file works everywhere else, so why won't it show in the browser?
The good news is that an SVG that “won't show” is rarely beyond repair. SVG (Scalable Vector Graphics) is simply an image made of text-based code rather than pixels. When it doesn't render, the problem usually comes from a small, predictable set of issues: a missing attribute, an incorrect file path, a color that blends into the background, or a server delivering the file incorrectly. Even better, most of these issues become apparent as soon as you paste the code into a live SVG renderer. This guide is based on a simple idea: an SVG is code. You can inspect, edit, and refine it directly. When you need to turn that code into a clean, usable SVG image, SVGMaker provides a straightforward way to do it online. Paste it into a tool like the SVG Code Editor, and it shows your markup in a live preview so you can see exactly where things go wrong. Below are the 12 most common reasons your SVG isn't showing in the browser, along with fixes you can apply in about 30 seconds.
Quick Diagnosis: What Kind of Problem Do You Have?
Before you start changing code, spend ten seconds figuring out which category of problem you're dealing with. The symptom usually points straight at the cause.
| What you see | Likely cause | Fixes to try first |
|---|---|---|
| Completely blank space, no icon at all | Missing xmlns, zero size, or a bad file path | Fixes 1, 2, 3 |
| Broken-image icon (like a missing photo) | Wrong path (404) or wrong MIME type | Fixes 2, 8 |
| SVG loads but is invisible | Fill/stroke color, CSS hiding it, or no viewBox | Fixes 4, 5, 6 |
| SVG shows but is the wrong size | Missing width/height or viewBox mismatch | Fixes 3, 4 |
| Parts of the artwork are cut off or missing | viewBox too small, or <img> stripping features | Fixes 4, 10 |
| Works in one browser but not another | Browser-specific quirks or invalid syntax | Fixes 11, 12 |
| Blocked in console (security error) | Content Security Policy or CORS | Fixes 7, 9 |
The 10-second test: copy your SVG markup and paste it into the SVG Code Editor. This is the “SVG code to SVG” check, the editor renders your raw code straight to a picture.
- If it renders there but not on your page, your SVG code is fine, the problem is delivery (file path, MIME type, CORS, CSP, or how you embedded it). Focus on fixes 2, 7, 8, 9, and 10.
- If it's blank or broken in the editor too, the problem is inside the code. Focus on fixes 1, 3, 4, 5, and 11.
This single test saves you from guessing and tells you exactly which half of the problem to focus on.
12 Fixes That Work in 30 Seconds
1. Add the xmlns Namespace Declaration
Every standalone SVG needs an XML namespace declaration so the browser knows it's dealing with SVG and not some generic XML. Without it, an SVG loaded as a file or via an <img> tag often refuses to render at all.
If you paste the first version into the editor and nothing shows, adding xmlns="http://www.w3.org/2000/svg" to the root <svg> tag is almost always the fix. (Inline SVG written directly in HTML is more forgiving, but adding the namespace never hurts.)
2. Check the File Path
If you're loading the SVG with <img src="...">, background-image, or <object>, a wrong path is the number-one culprit behind the broken-image icon. The browser is asking for a file that isn't where you told it to look.
Open your browser's DevTools (right-click → Inspect), go to the Network tab, and reload the page. Find your .svg request. A red 404 means the path is wrong. Double-check for typos, wrong folders, and relative-vs-absolute path mistakes (./icons/logo.svg vs /icons/logo.svg).
A quick way to isolate this: if the SVG renders fine when you paste its code into the editor but shows a broken icon on your page, the code is healthy and the path (or the way you're serving it) is the problem.
3. Set Width and Height (the Zero-Size Trap)
Sometimes the SVG loads successfully but renders at zero pixels, so it's technically “there” but invisible and takes up no space. This happens when an SVG has neither intrinsic width/height nor a viewBox to imply an aspect ratio.
Give it explicit dimensions:
In the code editor you can adjust width and height and watch the preview resize in real time, which makes the zero-size trap obvious the moment you fix it.
4. Add or Correct the viewBox
The viewBox defines the internal coordinate system of your SVG, essentially, which slice of the canvas the browser should draw. If it's missing, wrong, or too small, your artwork can appear cut off, tiny, off-center, or gone entirely.
The format is viewBox="min-x min-y width height". Make sure it actually contains your shapes. If your paths use coordinates up to 100 but your viewBox is 0 0 24 24, most of the drawing lives outside the visible area.
This is one of the easiest issues to spot visually. In the editor, zoom and pan around the canvas, if your artwork is sitting outside the frame, you'll see it and can widen the viewBox to bring it back in view.
5. Check Fill and Stroke Colors
An SVG can render perfectly and still be invisible if its color matches the background. White artwork on a white page, or a shape set to fill="none" with no stroke, shows nothing at all.
Look for fill="none", fill="#fff"/fill="white", or fill="transparent", and for strokes that have a width of zero. Give the shape a visible color:
The fastest way to catch this is to change the canvas behind the artwork. The editor has a background toggle (white, dark, transparent), flip it and a white-on-white icon suddenly appears against the dark background. It also helps you tell the difference between white artwork and a white background box sitting behind it.
6. Verify CSS Isn't Hiding It
If your SVG is inline in the HTML and still won't show, a stray CSS rule may be hiding it. Common offenders are display: none, visibility: hidden, opacity: 0, or a container with width: 0 / height: 0 / overflow: hidden.
Inspect the element in DevTools and check the computed styles. Watch for global rules like svg { height: 0 } or an inherited display: none from a collapsed parent. Because this is a page problem, not a file problem, it's the classic case where your SVG renders fine in the editor but disappears on your site, confirming the code is clean and the CSS is the culprit.
7. Fix Your Content Security Policy (CSP)
If your site sends a Content Security Policy header, it can block SVGs, especially inline SVGs or SVGs loaded from another domain. You'll usually see a clear error in the browser console mentioning a CSP directive.
Update your policy to allow the SVG source. For example, to permit SVG images from your own domain and inline use:
If you load SVGs that run scripts or use certain features, you may also need to adjust script-src or style-src. Only loosen what you actually need, tightening CSP is a security win, so add the minimum directive that lets your SVG through.
8. Set the Correct MIME Type
When you serve an SVG file, the server must tell the browser it's image/svg+xml. If it sends the wrong content type (like text/plain or application/octet-stream), the browser won't render it as an image, you'll often get a broken icon or a download prompt instead.
Configure your server to serve .svg with the right MIME type:
This is a delivery issue, not a code issue, which is why the SVG renders correctly when you paste its code into an editor but fails when served from your server. Check the Response Headers in the Network tab to confirm the Content-Type.
9. Handle CORS for Cross-Origin SVGs
If your SVG lives on a different domain (a CDN, an S3 bucket, another subdomain) and you load it in a way that requires cross-origin access, the browser may block it under CORS (Cross-Origin Resource Sharing) rules. The console will show a CORS error.
Fix it by having the hosting server send the right header:
(Use a specific origin instead of * when you can.) Alternatively, host the SVG on the same domain, proxy it through your own server, or, for small icons, just inline the SVG code directly into your HTML and skip the cross-origin request entirely.
10. Fix <img> Tag Limitations
An SVG loaded via <img src="icon.svg"> runs in a restricted mode: it can't execute embedded scripts, load external stylesheets, or pull in external resources (like fonts or other images). If your SVG relies on any of those, it'll look broken or partly empty inside an <img> tag, even though the file itself is fine.
You have three options:
- Inline the SVG directly in your HTML (
<svg>…</svg>), which unlocks full CSS and scripting. - Use
<object data="icon.svg" type="image/svg+xml"></object>, which keeps more capabilities than<img>. - Self-contain the SVG so it doesn't depend on external resources, embed fonts or convert text to paths, and inline any styles.
If you're not sure whether your SVG depends on external assets, open it in the editor and scan for external hrefs, @import, or references to fonts that aren't embedded.
11. Debug Invalid Syntax
SVG is XML, and XML is strict. A single unclosed tag, a stray character, an unquoted attribute, or wrongly nested elements can stop the whole graphic from rendering. Design tool exports and hand-edited files are the usual sources of malformed markup.
This is where rendering code back to SVG really pays off. Paste your markup into the editor, which runs on Monaco (the same engine as VS Code) with real-time validation, so invalid syntax gets highlighted with an error message pointing at the exact line. Fix the flagged issue, run the one-click format (Prettier) to tidy the structure, and the preview springs back to life.
12. Browser-Specific Issues
Occasionally your SVG is valid and served correctly, but a specific browser renders it differently. Safari can handle certain transform and CSS-animation behavior differently from Chrome; Firefox may render embedded fonts differently; and very old browsers lack support for newer SVG features like mask, filter, or CSS variables inside SVG.
To narrow it down, test the same file across browsers. If it works everywhere except one, look for advanced features that browser may not support and provide a fallback (for example, convert text to paths so font rendering can't vary). Confirming the base file is valid in the editor first tells you the issue is browser behavior, not the SVG itself.
Fix It Faster: Diagnose in the SVG Code Editor
Most of the fixes above share one workflow: turn your SVG code back into a picture, see what's wrong, change it, and watch the fix happen live. That's exactly what the SVG Code Editor from SVGMaker is built for.
- Paste code, get an instant render. Drop in your markup and it renders immediately, the core “SVG code to SVG” check that tells you whether the problem is in the file or in the delivery.
- Real-time validation. The Monaco editor highlights invalid syntax as you type, so unclosed tags and bad attributes surface instantly (fix 11).
- One-click formatting. Prettier cleans up minified or messy exports so you can actually read the structure and spot a missing
viewBoxor strayfill. - Background toggle. Switch between white, dark, and transparent to catch invisible white-on-white artwork (fix 5) and tell real transparency from a background rectangle.
- Zoom and pan. Find artwork that's sitting outside a too-small
viewBox(fix 4). - Export anywhere. Once it renders, export to SVG, PNG, or even React components.
If the problem is just an unwanted background box, the Remove Background from SVG Files Online AI tool can remove it in one step while keeping your file fully vector and ready to reuse.
Which Fix Should You Use?
| Your situation | Best fix | Why |
|---|---|---|
| Blank space, loaded as a file | Fix 1, add xmlns | Standalone SVGs need the namespace to render |
| Broken-image icon | Fix 2 / 8, path & MIME type | The browser can't find or can't identify the file |
| Loads but invisible | Fix 5, check fill/stroke | Color likely matches the background |
| Shows at the wrong size or clipped | Fix 4, correct the viewBox | The coordinate system doesn't match the artwork |
| Fine in the editor, gone on your page | Fix 6 / 7 / 9, CSS, CSP, CORS | The code is clean; the page or server is blocking it |
| Won't render anywhere | Fix 11, debug syntax | Malformed XML stops the whole graphic |
| Works in Chrome, not Safari | Fix 12, browser quirks | Unsupported feature; add a fallback |
Not sure which bucket you're in? Run the 10-second test, paste the code into the editor and let the render (or the lack of one) point you to the right column.
Frequently Asked Questions
1. Why does my SVG work in the code editor but not on my website?
Because the file itself is fine, the problem is in how it's being delivered or embedded. When an SVG renders correctly in the editor but not on your page, look at the file path (a 404 in DevTools), the server's MIME type (image/svg+xml), CORS headers for cross-origin files, your Content Security Policy, and any CSS hiding the element. Those are fixes 2, 6, 7, 8, and 9 above.
2. Why is my SVG blank but still takes up space on the page?
The SVG is loading and being sized, but nothing is being drawn. This usually means the artwork's fill or stroke color matches the background (white on white), the shapes sit outside the viewBox, or a fill="none" was left in place. Toggle the background in the editor to reveal white artwork, and check the viewBox covers your coordinates.
3. Does an SVG need width and height to show?
Not always, but it needs something that defines its size. If an SVG has no width/height and no viewBox, it can render at zero pixels and disappear. Add explicit width and height, or a viewBox that implies an aspect ratio. See fix 3.
4. Why does my SVG show up as a broken image icon?
A broken-image icon almost always means the browser requested the file and either couldn't find it (wrong path, 404) or the server sent the wrong MIME type so it wasn't treated as an image. Check the Network tab in DevTools: a 404 points to the path (fix 2), a wrong Content-Type points to the MIME setting (fix 8).
5. How do I check if my SVG code is valid?
Paste it into an SVG code editor with validation. The SVG Code Editor uses the Monaco engine to highlight syntax errors in real time and can auto-format the markup with Prettier, so unclosed tags, bad nesting, and stray characters are easy to find and fix. This is the fastest way to confirm your markup is well-formed before you use it.
6. Why does my SVG look fine in Chrome but different in Safari or Firefox?
Browsers implement some SVG and CSS features differently, transforms, animations, embedded fonts, masks, and filters are common trouble spots. Confirm the base file is valid, then look for advanced features the failing browser may not support and add a fallback (for instance, convert text to paths so font rendering stays consistent). See fix 12.
7. Do I need to add xmlns to inline SVGs in my HTML?
For SVGs written directly inside HTML, the browser is forgiving and usually renders them without it. But for standalone .svg files or SVGs loaded through <img> and <object>, the xmlns="http://www.w3.org/2000/svg" declaration is required. Adding it everywhere is a safe habit. See fix 1.
8. My SVG is really an embedded image, why won't these code fixes help?
Some “SVG” files are actually a PNG or JPG wrapped in SVG tags (look for an <image href="data:image/png;base64,…"> tag). If that raster data is broken or the base64 is truncated, no amount of viewBox or fill tweaking will help, because there's no real vector to render. In that case you'll need to re-create the graphic as a true vector or fix the source image.
Conclusion
An SVG that won't show in the browser feels mysterious, but it rarely is. Because an SVG is just code, you can always render that code back into a picture to see what's happening, and once you can see it, the fix is usually seconds away.
The workflow is simple: run the 10-second test to figure out whether the problem lives in the code or in the delivery, then apply the matching fix from the 12 above. Missing xmlns, a zero-size render, a too-small viewBox, a white-on-white fill, a 404 path, a wrong MIME type, a blocking CSP or CORS rule, an <img> limitation, invalid syntax, or a browser quirk, that's the entire list, and each one has a 30-second solution.
The fastest way through all of it is to paste your markup into the SVG Code Editor, let the live preview and validation show you exactly what's wrong, fix it in place, and export a file that renders everywhere.
