I found this thread about SVG in the firefox img-tag bug "external SVG not loaded from img tag": https://bugzilla.mozilla.org/show_bug.cgi?id=276431 and it cites some interesting ways to visualize svg in wikipedia, that might be useful to inspire some wikimedia developer here: --- Comment #42 from Jeff Walden (remove +bmo to email) &lt;jwalden+bmo(a)mit.edu&gt; 2007-10-24 14:14:19 PDT --- While SVG may in reality have been designed as a document format, its uses in practice are primarily as an image/graphics format, whose natural home in the mind of a web developer has always been in <img>. I don't think you can reasonably fight this intuition, particularly without support from other browsers. --- Comment #43 from Guilherme Fonseca &lt;fonseca(a)cs.umd.edu&gt; 2007-10-24 14:42:29 PDT --- Let's look, for example, at the following wikipedia image page: http://en.wikipedia.org/wiki/Image:Hexahedron.svg It contains a PNG preview of an SVG image and a link to it. I believe that it would be cleaner if the preview used the svg image itself, and left rendering of the SVG for the web browser. --- Comment #44 from Jeff Walden (remove +bmo to email) &lt;jwalden+bmo(a)mit.edu&gt; 2007-10-24 14:58:06 PDT --- (In reply to comment #43) itself, It would indeed, but I don't think that's quite the distinction being made. The question is whether it's worthwhile to support <img> when perfectly adequate support already exists in <iframe>, <object>, etc. with understood and effective security mechanisms in place to prevent the SVG (or any other document format loaded instead) from escaping its prison. (There's no reason Wikipedia couldn't do that now, with Accept or user-agent detection.) Those security mechanisms would have to be modified or reinvented for supporting SVG in <img>, or the document-support code would have to be modified to provide an <img>-style context; implementing either is a decent-sized task with lots of potential for regressions (and security ones, at that).