kicked off by this blog entry, and improved by comments on this message (thanks), still open for improvements, in text and certainly also markup.

I have seen many, many different reasons for an SVG file not to result in an image. Some happen often, some rarely. Let's try to make a rather complete list:

SVG Document Shown As XML Text In Browser

Problem: This XML file does not appear to have any style information associated with it

The most likely reason is that you have not declared the proper namespace in the <svg> element. Ensure that the <svg> element has the SVG namespace declaration as in:

<svg xmlns="http://www.w3.org/2000/svg" ... >

It is also a good idea to include the xlink: namespace declaration: xmlns:xlink="http://www.w3.org/1999/xlink".

Rendering is not Perfect

- viewer not perfect. As with any data format, the interpreter is not perfect. Over the years HTML support has become pretty darn good; SVG is getting there. http://www.codedread.com/svg-support.php has a measure for how good the different viewers are. At http://browsershots.org/ you can try out any (static) page/image on many different browsers. Or just use the best release of the moment: Opera.

- Maybe the SVG is not really SVG. Not conforming to the SVG specification, also known as invalid. Next to strict viewers as for example Batik, i advise the W3C validator to check. Remember though that the validator is good, but not perfect. For example it doesn't like perfectly valid foreign namespace content, as for example 'embedded' application round-trip information, like in Inkscape SVG.

- Maybe the .svgz file is not really SVGZ. An SVGZ file should be a gzipped SVG file. Many so-called zipping applications, WinZip is an example, have a different than gzip method as their default. Some people even think that renaming .svg to .svgz automatically turns the SVG content into SVGZ, which is of course wrong.

- It's rendered off-screen or too small to result in visible pixels. change viewBox and preserveAspectRatio

- Things can have the same color as the background. Or (fill/stroke) colors are not set.

- Maybe the SVG file doesn't have any graphical elements in it at all. Maybe a script was meant to add them later. If the script is broken, nothing will happen. jslint, FireBug (Firefox) and Dragonfly (Opera) can help you figure out the script.

- Try http://web-sniffer.net to see if the server sends it as the right Content-Type (also known as MIME-type). It should be "image/svg+xml"
Your server can also be ill-configured such that it compresses all .svgz files a second time. A symptom of this problem is that your .svgz files will be served with the header: Content-encoding: gzip, gzip

-Reference loops i.e. a marker points to itself as the marked element.
More complicated loops are possible.

-Missing units in css font sizes.

-Spaces in numeric attribute values.

-Not using namespace aware methods when creating dynamic content.

-Some problems with SVGZ, and with server configuration are mentioned
already. But one thing still missing rom the list is that Firefox
doesn't display SVGZ files when the server doesn't send the correct
content-encoding header, which also means that viewing local SVGZ
files over the file: protocol never works. In such cases the browser
tries to parse the compressed file as XML without uncompressing it
first, resulting in an error message. (The same problem certainly occurs with other Mozilla based browsers
and maybe with some other SVG viewers.)

Sometimes not showing an SVG image is the result of the HTML that is using it, or mixing it in. As there are a few different ways of doing this, each with multiple ways of doing it wrong, i won't at this moment go into them.

As tools are getting better, you won't run into those bugs that often anymore. But at least you know what to do when it happens.

PS: If some application generated your broken SVG content, make sure to report it, so the cause can be fixed.