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 the reliable, infinitely scalable alternative to raster formats — and most of the time they are. But when an SVG refuses to render in a browser, the failure mode is often silent and confusing. You get a broken image icon, a blank white rectangle, or simply nothing where your graphic should be. Unlike a corrupt JPEG, which at least throws an obvious error, a broken SVG can look fine in a text editor and still display nothing in Chrome, Firefox, or Safari. The root causes fall into a few distinct categories: incorrect MIME types served by the web server, malformed XML inside the file itself, security restrictions that strip inline scripts or external references, and viewport or sizing problems that technically render the SVG but at zero visible size. Each of these has a different fix, and conflating them wastes a lot of time. This article walks through each cause specifically, with the settings and file attributes you actually need to check — not vague advice to 'make sure your file is valid.' One important caveat before we start: some SVG rendering problems originate in how a file was exported from a design tool like Illustrator or Figma, and others are introduced during file conversion. If you converted a file to SVG using an online tool and it broke in the process, that is a separate problem from a correctly exported SVG that your server is misconfiguring. We will distinguish between the two throughout.
Wrong MIME Type: The Server-Side Problem Most Developers Miss
When you embed an SVG using an `<img>` tag or reference it as a CSS background image, the browser checks the Content-Type header the server sends alongside the file. If that header says `text/plain` or `application/octet-stream` instead of `image/svg+xml`, most browsers will refuse to render it — even if the file itself is perfectly valid. This is one of the most common causes of SVG failure in production environments, and it almost never shows up during local development because developers typically open SVG files directly from disk rather than through a server. The problem only appears after deployment. To diagnose it, open Chrome DevTools (F12), go to the Network tab, reload the page, click on your SVG request, and look at the Response Headers section. The Content-Type line should read exactly `image/svg+xml`. If it says anything else, the fix is on the server side, not in the SVG file. For Apache servers, add this line to your `.htaccess` file: `AddType image/svg+xml .svg .svgz`. For Nginx, add `image/svg+xml svg svgz;` inside the `types` block in your `nginx.conf`. On IIS, you add the MIME type through Internet Information Services Manager under the server's MIME Types section, mapping the `.svg` extension to `image/svg+xml`. If you are on a managed hosting platform like Netlify or Vercel, you can set custom headers in a `netlify.toml` or `vercel.json` configuration file respectively. Netlify's syntax uses a `[[headers]]` block where you specify the path pattern and the `Content-Type` value. This is a five-minute fix once you know what you are looking for, but it is invisible until you check the network panel.
Malformed XML: When the SVG File Itself Is the Problem
SVG is an XML-based format, which means it follows strict parsing rules. A missing closing tag, an unescaped ampersand in an attribute value, or a duplicate `id` attribute can cause the entire file to fail silently in some browsers and throw a parse error in others. Firefox tends to be more explicit about XML errors than Chrome — if your SVG renders in Chrome but not Firefox, malformed XML is the first thing to check. Open the SVG file directly in Firefox by dragging it into the browser window. If the XML is broken, Firefox will show you an error message with a line number: something like 'XML Parsing Error: not well-formed at line 47, column 12.' That line number is your starting point. Open the file in a text editor that shows line numbers — VS Code works well — and look at that exact location. Common culprits include: ampersands in `href` or `xlink:href` attributes that should be written as `&`, unclosed `<path>` or `<g>` elements, and encoding issues where a design tool has exported characters outside the ASCII range without proper UTF-8 declaration. The SVG file should start with `<?xml version="1.0" encoding="UTF-8"?>` if it contains any non-ASCII characters. Another frequent issue is files exported from older versions of Adobe Illustrator that include proprietary Illustrator XML namespaces. These are not technically invalid, but they add significant file weight and occasionally confuse parsers. When you run such a file through a conversion tool or optimizer like SVGO, those namespaces get stripped, which is usually fine — but if the file relies on Illustrator-specific attributes for its appearance, stripping them can change how it looks or break it entirely. If you converted a file to SVG using CocoConvert and the output has XML errors, please use the feedback button on the result page. Conversion artifacts are something we actively track and fix.
Inline SVG and Content Security Policy Conflicts
Inline SVG — SVG markup embedded directly in an HTML document rather than referenced as a separate file — behaves differently from SVG loaded via `<img>` tags. It becomes part of the DOM, which means it is subject to the page's Content Security Policy (CSP). If your site has a strict CSP that blocks inline scripts or restricts certain resource origins, parts of your SVG may silently fail to render. This is particularly relevant for SVGs that include `<script>` elements, `<use>` elements that reference external symbols, or CSS animations defined in `<style>` blocks inside the SVG. A CSP directive like `script-src 'self'` will block any inline scripts in your SVG. A directive like `img-src 'self'` may block external images referenced inside the SVG via `<image href="https://external-domain.com/...">` tags. To check whether CSP is the issue, open the browser console (not the Network tab — the Console tab). CSP violations appear there as red error messages that explicitly name the blocked resource and the policy directive that blocked it. The message format is standardized and readable: 'Refused to load the script because it violates the following Content Security Policy directive: script-src self.' The fix depends on what your SVG actually needs. If it needs inline styles, add `'unsafe-inline'` to your `style-src` directive — though be aware this weakens your CSP. A better approach for SVGs with animations is to move the CSS into an external stylesheet and reference it from the SVG using `<?xml-stylesheet type="text/css" href="styles.css"?>`. For `<use>` elements referencing external files, you may need to either inline the referenced symbols or adjust your `img-src` policy to allow the external origin. SVGs converted from other formats by CocoConvert or any other tool will not contain scripts, so script-src conflicts will not apply to converted files. But style-src conflicts can still occur if the converted SVG uses inline CSS for fill colors or font declarations.
Viewport and ViewBox Misconfigurations That Make SVG Invisible
This is the category of SVG problem that is most maddening because the SVG is technically rendering — it is just rendering at a size of zero, or in a location outside the visible area. You will not see a broken image icon. You will see nothing, and the browser's inspector will show the SVG element is present and has no errors. The SVG `viewBox` attribute defines the coordinate system of the graphic's content. The `width` and `height` attributes on the root `<svg>` element define how much space it takes up in the document. When these are missing or mismatched, the results are unpredictable. A common failure: an SVG exported from Figma with `width="100%"` and `height="100%"` but no explicit `viewBox`. When embedded in a container that has no defined height, the SVG collapses to zero height. The fix is to either add a `viewBox` attribute that matches the original artboard dimensions — for example `viewBox="0 0 800 600"` for an 800×600 artboard — or to give the containing element an explicit height in CSS. Another common failure: an SVG where the content is drawn at coordinates far outside the viewBox. If your artboard is `viewBox="0 0 100 100"` but the path data starts at coordinates like `M 500 500`, the graphic is being drawn 400 units off-screen. This happens when shapes are moved in a design tool after the artboard is set, and the export does not recalculate the coordinate space. The fix is to select all objects in your design tool and use 'Reset Bounding Box' or the equivalent, then re-export. To diagnose viewport issues, inspect the SVG element in DevTools and check its computed dimensions. If width or height shows as 0, the sizing is the problem. You can also temporarily add `style="border: 1px solid red; width: 200px; height: 200px;"` directly to the `<svg>` tag to force a visible size and see if any content appears.
Font and External Resource Loading Failures Inside SVG
SVG files can reference external resources: fonts via `<text>` elements with `font-family` declarations, images via `<image>` elements, and gradients or filters defined in separate files. When any of these external references fail to load, the SVG may render partially or not at all, depending on how critical the missing resource is to the graphic. Font failures are the most common. An SVG that uses a custom font and embeds the font name as a text attribute will fall back to the system default font if that font is not available. This does not usually break rendering, but it can make text overflow its bounds and push other elements out of position, making the SVG look broken even though it technically rendered. The reliable fix is to convert text to outlines (paths) before exporting — in Illustrator this is Type > Create Outlines, in Inkscape it is Path > Object to Path. This eliminates the font dependency entirely. External image references inside SVG are trickier. An `<image>` element pointing to an absolute URL will fail if that URL is unreachable, if CORS headers are not set on the image server, or if a CSP blocks the origin. The browser will render the SVG but leave a blank space where the image should be. There is no error icon — just silence. Check the Network tab for failed requests with status 0 (blocked by CORS or CSP) or 404. If you are converting a file that contains embedded raster images — a common case when converting PDF or AI files to SVG — CocoConvert embeds those images as base64 data URIs inside the SVG output, which eliminates external reference problems. However, this makes the file significantly larger. A PDF with several high-resolution photos converted to SVG can easily produce a file over 5MB, which may cause its own performance problems. For those cases, converting to PNG or WebP is often the more practical choice, and we will say so plainly rather than pretend SVG is always the right output format.
When Conversion Is the Source of the Problem (and What to Do About It)
Not every SVG rendering failure originates in the browser environment. Sometimes the SVG file is broken before it ever reaches a server or browser, because the conversion process that created it introduced errors. This is worth addressing directly, because it changes where you should focus your debugging effort. Common conversion artifacts include: path data with extremely high precision (15+ decimal places) that bloats the file and occasionally causes parser timeouts in older browsers; incorrect color space conversions that shift fills from RGB to CMYK values that SVG does not support; missing namespace declarations when converting from formats that use proprietary XML extensions; and broken text encoding when the source file contains characters from non-Latin scripts. If you converted a file to SVG and it does not render, the fastest diagnostic is to open the SVG in Inkscape (free, cross-platform) and see whether it renders correctly there. Inkscape has a more permissive SVG parser than most browsers. If it looks correct in Inkscape but broken in Chrome, the issue is likely a browser-specific parsing problem or a namespace issue. If it looks broken in Inkscape too, the conversion output itself is corrupt. CocoConvert uses well-maintained conversion libraries and we test output against the W3C SVG specification, but we cannot guarantee perfect output for every source file. Highly complex AI files with hundreds of layers, PDFs with transparency effects, or files using features specific to CorelDRAW or Affinity Designer may produce imperfect SVG output. In those cases, the most reliable path is to open the source file in its native application, export directly to SVG using the application's own export dialog, and use CocoConvert for format pairs where our conversion pipeline is stronger — such as PNG to SVG for simple graphics, or SVG to PDF for print workflows. If you encounter a conversion that produces a broken SVG, the most useful thing you can do is report it using the feedback form on the results page, including the original file if possible. Specific reproduction cases are how we improve the conversion pipeline, and we take them seriously.