SVG Not Rendering in Browser? Common Causes
Why Your SVG Shows a Broken Image Icon (or Nothing at All)
SVG files are supposed to be easy. As an infinitely scalable alternative to raster formats, they're usually reliable. But when an SVG refuses to render, the failure is often silent and confusing. You get a broken image icon, a blank white rectangle, or just an empty space where your graphic should be. A corrupt JPEG at least looks obviously broken; a bad SVG can look perfect in a text editor and still show nothing in Chrome, Firefox, or Safari. The problems usually boil down to a few distinct issues: an incorrect MIME type from the web server, malformed XML inside the file, security policies blocking inline code, or sizing problems that render the SVG at zero visible size. Each has a different solution, and mixing them up will waste hours. This guide walks through each cause with the specific settings and attributes you need to check, not just vague advice to 'validate your file.' One important distinction before we start: some SVG issues begin in the design tool (Illustrator, Figma) during export, while others happen during file conversion. If you used an online tool to convert a file to SVG and it broke, that's a different class of problem than a perfect SVG that your server is misconfiguring. We'll be sure to distinguish between the two.
Wrong MIME Type: The Server-Side Problem Most Developers Miss
When you use an `<img>` tag or CSS `background-image` to display an SVG, the browser inspects the Content-Type header sent by the server. If that header reads `text/plain` or `application/octet-stream` instead of the correct `image/svg+xml`, most browsers will simply refuse to render the image. The file itself could be flawless. This is one of the most common causes of broken SVGs in production, and it's a ghost in local development. Why? Because locally, you're probably just opening the file from disk, not serving it. The problem only rears its head after you deploy. To diagnose this, open your browser's DevTools (F12), switch to the Network tab, and reload the page. Find your SVG in the request list, click it, and look at the Response Headers. The `Content-Type` line must say `image/svg+xml`. If it says anything else, you've found your problem. The fix is on the server, not in the file. On Apache, you can fix this by adding `AddType image/svg+xml .svg .svgz` to your `.htaccess` file. For Nginx users, add `image/svg+xml svg svgz;` inside the `types` block of your `nginx.conf`. If you're on IIS, you'll need to use the Internet Information Services Manager to add a MIME type mapping for the `.svg` extension to `image/svg+xml`. If you're using a managed platform like Netlify or Vercel, this is handled in a configuration file (`netlify.toml` or `vercel.json`). Netlify's syntax, for example, uses a `[[headers]]` block to set the `Content-Type` for a given path. It's a five-minute fix that can save you hours of frustration, but only if you know to look in the network panel.
Malformed XML: When the SVG File Itself Is the Problem
An SVG is an XML document, which means it follows strict parsing rules. One missing closing tag, one unescaped ampersand, or a duplicate `id` can make the entire file fail silently in some browsers. Here's a tip: if your SVG renders in Chrome but not Firefox, malformed XML is the prime suspect. Firefox is much more explicit about XML errors. To see for yourself, drag the SVG file directly into a Firefox window. If the XML is busted, Firefox will show you a clear error message, complete with a line and column number: 'XML Parsing Error: not well-formed at line 47, column 12.' That's your treasure map. Open the file in a text editor like VS Code and go to that exact spot. What are you looking for? Often it's an ampersand (`&`) in a link that should have been written as `&`. Or you might find an unclosed `<path>` or `<g>` element. Encoding issues are another classic, where a design tool exports characters outside the standard ASCII range without declaring UTF-8. Your SVG file should always start with `<?xml version="1.0" encoding="UTF-8"?>` if it contains any non-ASCII characters. Older versions of Adobe Illustrator loved to export files with proprietary XML namespaces. While not technically invalid, this adds useless weight and can sometimes confuse parsers. Running these files through an optimizer like SVGO typically strips those namespaces, which is good. The danger is if the graphic's appearance somehow depended on those proprietary attributes, in which case cleaning the file might unexpectedly break it. If you converted a file to SVG using CocoConvert and the output has XML errors, please let us know via the feedback button on the result page. We actively hunt down and fix these kinds of conversion artifacts.
Inline SVG and Content Security Policy Conflicts
Pasting SVG markup directly into your HTML is a powerful technique, but it comes with a major catch: the SVG becomes part of the DOM. This means it's now subject to your page's Content Security Policy (CSP). A strict CSP can silently disable parts of your SVG, leading to confusion. This is especially true for SVGs containing `<script>` elements, `<style>` blocks for animations, or `<use>` elements that reference external symbol definitions. A common CSP directive like `script-src 'self'` will block any inline scripts inside your SVG from running. A directive like `img-src 'self'` might prevent the SVG from loading an external image referenced via `<image href="https://external-domain.com/...">`. The good news? The browser will tell you exactly what's wrong. Open the browser's developer console (the Console tab, not Network) and look for red error messages. CSP violations are very explicit, stating which resource was blocked and which policy directive was responsible, like: 'Refused to load the script because it violates the following Content Security Policy directive: script-src self.' How you fix this depends on your SVG's needs. You could add `'unsafe-inline'` to your `style-src` directive, but this weakens your security policy, so I'd strongly advise against it. A much better solution for animated SVGs is to move the CSS into an external stylesheet and link it with `<?xml-stylesheet type="text/css" href="styles.css"?>`. For `<use>` elements pointing to external files, you'll either need to inline the symbols or adjust your `img-src` policy to whitelist the origin. SVGs generated by CocoConvert or similar tools won't have scripts, so you won't see script-src conflicts with them. However, style-src conflicts are still possible if the converted SVG uses inline CSS for colors or fonts.
Viewport and ViewBox Misconfigurations That Make SVG Invisible
This is the most infuriating kind of SVG problem. The browser is rendering the SVG perfectly, but it's rendering at zero size or somewhere offscreen. You don't see a broken image icon; you see nothing. Anyone who has stared at a blank space in DevTools, seeing the `<svg>` element right there but nothing on the screen, knows this particular pain. The key is the relationship between the `viewBox` attribute, which defines the graphic's internal coordinate system, and the `width` and `height` attributes, which define how much space the SVG occupies on the page. When they are missing or mismatched, chaos ensues. You'll often see this with Figma exports: an SVG is given `width="100%"` and `height="100%"` but has no `viewBox`. If you put that SVG in a container that doesn't have an explicit height, the SVG collapses to zero height. The fix is to add a `viewBox` that matches the original artboard dimensions (e.g., `viewBox="0 0 800 600"`) or give the containing element a height in your CSS. Another classic is an SVG where the path data is drawn at coordinates far outside the `viewBox`. If your `viewBox` is `"0 0 100 100"` but your path data starts at `M 500 500`, the graphic is being drawn 400 units off-screen. This happens when you move shapes around in a design tool without resetting the artboard's origin. To fix it, go back to your design tool, select all objects, and use a 'Reset Bounding Box' command or its equivalent, then re-export. To diagnose this, inspect the SVG in DevTools. If its computed width or height is 0, sizing is the culprit. You can also force the issue by temporarily adding `style="border: 1px solid red; width: 200px; height: 200px;"` directly to the `<svg>` tag. This will create a visible box and reveal if any part of your graphic is appearing.
Font and External Resource Loading Failures Inside SVG
An SVG isn't always self-contained. It can reference external resources like fonts, images, gradients, and filters. When these external calls fail, the SVG might render partially or look completely wrong, depending on how critical the missing piece is. Font failures are a frequent headache. An SVG that specifies a custom font in a `<text>` element will fall back to a system default if that font isn't available. This usually doesn't break rendering entirely, but it can cause text to overflow its container and throw the whole layout off. My advice: always convert text to outlines (paths) before exporting an SVG for web use. In Illustrator, it's Type > Create Outlines; in Inkscape, it's Path > Object to Path. This completely eliminates the font dependency and a whole class of problems. External images inside an SVG are even more finicky. An `<image>` tag pointing to a URL can fail because the URL is down, because the image server lacks proper CORS headers, or because a CSP blocks the origin. The browser won't show an error icon; it will just render a blank space where the image should be. Check your Network tab for requests with a 404 status or a status of 0, which often indicates a CORS or CSP block. If you're converting a PDF or AI file that contains raster images, CocoConvert will embed those images directly into the SVG as base64 data URIs. This solves the external reference problem but can make the SVG file huge. A PDF with a few photos can easily become a 5MB+ SVG. In those cases, we'll say it plainly: converting to PNG or WebP is the more practical choice. We're not going to pretend SVG is always the right answer.
When Conversion Is the Source of the Problem (and What to Do About It)
Sometimes the problem isn't your browser or your server. The SVG file itself was broken from the start, a casualty of a bad conversion process. It's important to recognize this possibility, because it means you should stop debugging your environment and start scrutinizing the file. Common conversion artifacts include path data with absurdly high precision (15+ decimal places), which bloats files and can time out parsers; incorrect color space conversions from CMYK to un-supported RGB values; and broken text encoding if a source file used non-Latin scripts. You might also see missing namespace declarations when converting from formats that rely on proprietary XML. If you suspect a bad conversion, the fastest way to check is to open the SVG in Inkscape. It's free, cross-platform, and has a very forgiving SVG parser. If the file looks correct in Inkscape but is broken in Chrome, the issue is likely browser-specific. If it's broken in Inkscape too, then the conversion process itself failed and the output is corrupt. CocoConvert uses robust conversion libraries, but no automated tool is perfect. A highly complex AI file with hundreds of layers, or a PDF that relies heavily on transparency effects, can produce imperfect SVG output. In these situations, the most reliable path is often to open the source file in its original application, export to SVG directly, and use CocoConvert for format pairs we excel at, like converting simple PNGs to SVG or SVG to PDF for print. If you do get a broken SVG from a conversion, please report it using the feedback form on the results page, and include the original file if you can. Specific examples are how we improve the conversion pipeline for everyone, and we take those reports seriously.