This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:SVG help

Create a new request

SVG help

Scalable vector graphics is a commonly used file format for providing a geometrical description of an image using basic objects such as labels, circles, lines, curves and polygons. An image can be reduced or enlarged to an arbitrary size, and will not suffer image data loss, nor will it become pixelated. SVG makes an excellent format for artwork, diagrams and drawings. SVG images are defined in XML text files. This means that they can be searched, indexed, scripted and, compressed. Since they are XML files, SVG images can be edited with any text editor, but SVG-based drawing programs are also available.

However, the rendering engine used by wiki is not perfect, and may cause the image to be shown incorrectly, or differently from how it is displayed in your vector editor of choice. This page enables authors experiencing problems with SVG graphics to obtain some help in getting their images into wiki the way they intend.

Things we can help with

Understanding SVG

  • Questions about the SVG format

Using SVG appropriately

  • When to (or not to) use SVG

What you see is not what you get

  • Missing objects from files
  • Random filled boxes in the image
  • Images that are the wrong size
  • Font inconsistencies
  • Other weird and wonderful bugs

Something new

  • Questions that you can't find a better place for

Common problems

flowRoot does not appear

a picture containing SVG1.2-valid flowRoot

If black box appear, read c:User:JoKalliauer/RepairFlowRoot how to solve this issue, but do not remove those objects since they might contain text. The workarounds that one can employ are either not to use flowed text (by using the text tool without creating a text field), or convert the text to normal text (by Text-editor or sed-comand, or with Inkscape-GUI or with a Inkscape-batch), but to stroke the text using "object to path", since path-text is not recomended and increases file-size.

font-family issues

Rendering anomalies of small fonts in thumbnail views
Fallback fonts

Due to copyright restrictions, MediaWiki cannot use proprietary fonts that are commonly found on several proprietary operating systems. Fonts such as Geneva require licensing fees to distribute. rsvg will not be able to locate such fonts, and the text will fail to appear in the rendered image. There are three solutions to this issue:

  • One can substitute a font that is available on Wikipedia. This approach facilitates editability.
  • One can specify a generic font-family such as "sans-serif", "serif", or "monospace", but this can lead to inconsistent rendering. It is better to specify a font available on Wikipedia (such as Liberation Sans) with fallback fonts such as: font-family="Liberation Sans,Arial,Helvetica,sans-serif", in which you define a font-list with similar fonts that at least contain one font for each Operating System such as Wikimedia (e.g. Liberation Sans), Windows (e.g. Arial), Linux (e.g. Liberation Sans), Mac (e.g. Helvetica).
  • Since local rendering should be as close as possible to Wikipedia, it should use locally the same font as it will have on Wikipedia, if available. Therefore always define a Wikimedia-font first. Also, Wikimedia has synonyms for substituting fonts, such as "Arial" for "Liberation Sans"; therefore font-family="Arial,DejaVu Sans" will be rendered by "Liberation Sans" and not (as expected) by "DejaVu Sans".
  • Converting the text into paths increases file size, and is therefore generally disfavored (except for text logos, etc.).
  • Group the text, create a copy, and convert the copy to paths. Then either:
1. move the original, editable non-path text into a separate editable text layer that you make transparent (warning: this might be removed by SVG optimizers), or
2. move the original, editable non-path text outside the visible area (example: File:Essigsäuresynthesen.svg).

For ease of subsequent editing and significantly smaller file sizes, substituting the font with an available font is recommended. Many common fonts have non-proprietary alternatives that are similar in typographical style, resulting in minimal disruption to existing images during substitution. For a list of fonts available in Wikipedia, see available fonts on Meta.

Wikimedia has default fonts, and will use Liberation Serif for Times New Roman and Liberation Sans for Arial. For further fallbacks see c:Help:SVG#fallback.

Fonts that are available on Wikimedia servers may or may not be available on a visitor's machine. If the placement or appearance of text in the image is important and there is uncertainty about which fonts are installed on a visitor's machine, then converting text into path information may be necessary.

bad letter-alignment on small font-size

Librsvg calculates the letter-distances inaccurantly for font-sizes of 20px and below.

For a text like

<svg viewBox="0 0 100 100" xmlns="">
 <text x="20" y="30" font-size="5px">exampletext</text>

you can replace it with:

<svg viewBox="0 0 1000 1000" xmlns="">
 <text x="200" y="300" font-size="50px">exampletext</text>

or with

<svg viewBox="0 0 100 100" xmlns="">
 <g transform="scale(0.1)"><text x="200" y="300" font-size="50px">exampletext</text></g>

Missing embedded JPEG images

Normal image
Broken image

When a raster graphic is embedded in an SVG it is encoded into base64 data. That data is then assigned a MIME type in the <image> element. In the case of an embedded JPEG, the MIME type is "image/jpeg". Older versions of Inkscape (and possibly other editors) assigned the MIME type "image/jpg". While Inkscape and most web browsers will display such an SVG image just fine, the MediaWiki software that rasterizes the SVG file will have trouble with it. Not recognizing the MIME type "image/jpg" there will simply be an empty space where the image is supposed to be. The fix is to open the SVG file in a text editor, find the <image> element, locate "image/jpg", change it to "image/jpeg" and re-save. At right is an example of this problem. The Commons SVG Checker looks for this problem; see Commons:Commons:Commons SVG Checker/KnownBugs#Checks for details.

Rendering files

MediaWiki (the software from which Wikipedia is run) uses the librsvg-library to rasterize all of its svg files. The version of the rsvg program that is installed on wiki does not always correctly raster the Inkscape or SVG files, and does not recognize some formats in text-editor SVG files. The file manager GNOME Files or c:Commons:Commons_SVG_Checker relies on librsvg, so it can be used to check the quality before a SVG is uploaded.

Rendering Inkscape files

There is a simple work-around for the scarcities of librsvg. The operation "Stroke to Path", to be found under Menu>Path in Inkscape or via Ctrl+Alt+C, can be applied to all of the objects that are not rendered correctly. To keep the SVGs editable, this should only be done to the files intended for upload, and these files can be deleted afterwards.

As of February 2014, the objects that must be modified to render correctly by librsvg include:

  • Lines with arrow heads (the arrows need to be converted)
  • Text, that has been transformed, e.g. "Text on Path"
  • Compound objects created with the binary path tools (union, intersect etc.)

Rendering SVG files SVG files may require manual modification before being uploaded to Wikipedia. To achieve this:

  • Change all fonts to Wikipedia supported fonts as mentioned before. (E.g. change "Sans embedded" to "DejaVu Sans".)
  • Add "px" to all font-size references. (E.g. change "font-size:100" to "font-size:100px".)
  • Remove all additional x coordinate references in tspan elements. (E.g. change <tspan x="17583 17917 " y="10943"> to <tspan x="17583" y="10943">.)
  • [Not required for OO 2.3.0] Explicitly colour all text (e.g. black) by replacing relevant "stroke:none;fill:none" instances with "stroke:none;fill:rgb(0,0,0)" (note that simply explicitly colouring text black in OpenOffice 3.2.1 does not appear to work).

NB: Vector graphics line widths may also need to be set explicitly in Draw.

SVG code replacement guide (executing replace all using Nedit regular expressions)
Original text Replacement text
Sans embedded DejaVu Sans
tspan x="([0-9]*) ([0-9 ]*)" tspan x="\1"
<g style="stroke:none;fill:none"><text> <g style="stroke:none;fill:rgb(0,0,0)"><text>

This SVG export procedure has been tested using OO 2.3.0 and OO 3.2.1 with a simple .odg candidate.

Rendering text-editor SVG files

SVG files created from scratch in a text editor may make use of any valid SVG syntax, so long as your browser supports the given version of the SVG specification. On Wikipedia however, SVGs are interpreted by the librsvg-library to create PNG previews at different image sizes. That library only recognizes a subset of all valid SVG syntax, and may render your SVG without many features. In order to bypass these deficiencies in the library, there are certain parameters that need to be formatted in specific ways or be assigned a workaround value in order for librsvg to accurately render views of your SVG file.

<mask> parameter maskUnits="userSpaceOnUse"

The librsvg-library does not interpret the value of "userSpaceOnUse" for the parameter maskUnits correctly. To bypass this issue, replace maskUnits="userSpaceOnUse" with maskUnits="-10% -10% 120% 120%", and the SVG mask will render properly on Wikipedia.

parameter stroke-dasharray

The librsvg-library does not accept a stroke-dasharray parameter with values separated by spaces. Replace all spaces with commas to bypass this issue: e.g. stroke-dasharray="2 3 2 4"stroke-dasharray="2,3,2,4"


If you have a tricky SVG file with a problem not described, or can't quite figure out what the previous section was talking about, you can simply ask for assistance by posting a quick note hereafter that outlines the problem, as well as providing links to the files that are exhibiting these problems. Don't forget to sign your name with four tilde symbols (~~~~) and an editor will attempt to reply here to help!

When you are happy that a request has been fulfilled, just leave a note so that the request can be archived later, as needed.

An alternative source of help is Commons:Graphics village pump.

Current requests

Create a new request

Switching to .svg for chemistry file previously loaded as .png

I have been adding chemistry diagrams, for example

Protoporphyrin IX magnesium insertion.png
Protoporphyrin magnesium insertion.svg

I know that it would be better to use such diagrams in .svg format and I've worked out how to create them with software I have access to. I converted this one today and uploaded it on Commons as "Protoporphyrin_magnesium_insertion.svg". This looks fine when viewed natively but when inserted into a page the bottom part gets truncated, as here on the right.

Can you advise how to fix this? Thanks. Michael D. Turnbull (talk) 14:17, 9 June 2020 (UTC)

All of the coordinates lack units, which implies that their dimensions are measured in terms of pixels. The <svg> tag has the attributes height="105.03958mm" width="247.38542mm" but it has no viewBox= attribute which would specify exactly how many pixels should stretch across 247.38542mm (or along 105.03958mm). You either need to alter all of the coordinates to use millimetre dimensions, or add a viewBox= attribute. --Redrose64 🌹 (talk) 15:01, 9 June 2020 (UTC)

OK. I think I understand that. I used a text editor to add the attribute viewBox="0 0 2470 1050" preserveAspectRatio="none" which I assumed would give me the ~247 by 105mm translated into something useful. After uploading this as a new version of the file, I can see that the image rendered here to the right is no longer truncated BUT it seems very small, as it's squeezed into the top left of the viewing box. Is there a value for the viewBox attribute that would work well in general on Wikipedia? Note that I'm clueless about the detials of .svg files: I converted a .wmf file that my chemical drawing software can produce into the .svg one by using a free utility at Michael D. Turnbull (talk) 15:41, 9 June 2020 (UTC)

@Redrose64: I've experimented with a couple of other uploads, after looking at the Help pages whose URL you kindly provided. I'm still puzzled and getting the too-small picture. The first parts of my .svg file now looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  viewBox="0 0 2470 1050"
  preserveAspectRatio="xMaxYMax meet"
This clearly isn't fully correct. What next? Michael D. Turnbull (talk) 17:17, 9 June 2020 (UTC)
 Done Ah! Totally counterintuitive to me, by making the viewbox attribute = "0 0 1235 525" things get much better. So, the smaller the viewbox numbers the bigger the actual picture when rendered! I'll be able to sort this out now.... thanks for the tips. Michael D. Turnbull (talk) 17:36, 9 June 2020 (UTC)
Note to future readers. The version rendered in the image to the right here is now satisfactory. This .svg file was exported from Libre Office Draw (v. To see earlier buggy versions of the same drawing, see Wikipedia Commons for this image. Michael D. Turnbull (talk) 13:46, 11 June 2020 (UTC)

Problem with second version of azoxystrobin.svg


I created an .svg file to ACS standards (including atom colouring) for azoxystrobin and loaded it in Commons as a new version of the existing (first and only) one. As expected, my new version now replaces the old one on most Wikis where it is used (for example "French wikipedia".). However, it doesn't replace the diagram in the chembox at azoxystrobin, nor does it appear correctly in the file history section of "Commons for this file"., although it DOES look correct in the PNG preview on Commons. Similarly, the image included on the right here is still the old one! What is going wrong? I've replaced other image files on Commons without any such issues.

Incidentally, I note with this file and many other svgs in Commons that clicking on the PNG preview gives a poor image at full scale with a black background obscuring the picture. Is there a way to upload .svg to avoid this or is it a "feature" of the system? Michael D. Turnbull (talk) 14:19, 13 June 2020 (UTC)

The one at Azoxystrobin looks fine to me. It's probably your browser caching an old version. --Redrose64 🌹 (talk) 06:38, 14 June 2020 (UTC)
Wow, I never realised that browsers could cache things for so long! I've just re-booted my PC today and in Edge (the new Chromium-based version) which I was using yesterday, the file still looks wrong. Viewing the relevant web pages, including this one, in Internet Explorer looks perfect: must be the first case ever of IE being superior to Edge... Thanks for making this suggestion, which I would never have thought of. Michael D. Turnbull (talk) 11:41, 14 June 2020 (UTC)
In case anyone else has this problem, it can be fixed in the new Edge by setting it to clear cached image files on exit (go in to settings and search for "cache"). The browser defaults to retaining everything, including cookies and image data, but each type of data can be individually marked for deletion on exit. I did that and all the pages now look fine. Michael D. Turnbull (talk) 11:51, 14 June 2020 (UTC)

Using a <pattern> with <line>

Okay, I am trying to develop an SVG file template for creating images of tartan patterns. I figured out that I can use a <pattern> element for the tartan weave - I use a stroke-dasharray="2 2" to run the threads for either warp or weft. And then I want to use that pattern on a line with width=page size across the image, and its own stroke-dasharray with the tartan pattern for that color. The problem I am running into is that the <line> element requires the stroke property to specify the color of the line, but I also need to specify <line stroke="url(#pattern)"/> to apply the weave pattern onto the tartan color pattern. Is there a trick for specifying two parameters for the stroke property? I tried using a semicolon because my reference suggested it has some relation to CSS properties, but it didn't work. VanIsaacWScont 02:51, 22 June 2020 (UTC)

Try using this:
<svg ... viewBox="0 0 512 512" ...>
    <pattern id="warp_red" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="0" width="8" height="4" fill="red" stroke="none" />
    <pattern id="warp_green" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="0" width="8" height="4" fill="green" stroke="none" />
    <pattern id="warp_blue" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="0" width="8" height="4" fill="blue" stroke="none" />
    <pattern id="warp_yellow" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="0" width="8" height="4" fill="yellow" stroke="none" />
    <pattern id="weft_red" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="4" width="8" height="4" fill="red" stroke="none" />
    <pattern id="weft_green" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="4" width="8" height="4" fill="green" stroke="none" />
    <pattern id="weft_blue" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="4" width="8" height="4" fill="blue" stroke="none" />
    <pattern id="weft_yellow" patternUnits="userSpaceOnUse" width="8" height="8" patternTransform="rotate(-45)">
      <rect x="0" y="4" width="8" height="4" fill="yellow" stroke="none" />
  <g stroke="none">
    <rect x="0" y="0" width="512" height="256" fill="url(#weft_red)" />
    <rect x="0" y="0" width="256" height="512" fill="url(#warp_red)" />
    <rect x="0" y="112" width="512" height="32" fill="url(#weft_green)" />
    <rect x="112" y="0" width="32" height="512" fill="url(#warp_green)" />
    <rect x="0" y="256" width="512" height="256" fill="url(#weft_blue)" />
    <rect x="256" y="0" width="256" height="512" fill="url(#warp_blue)" />
    <rect x="0" y="368" width="512" height="32" fill="url(#weft_yellow)" />
    <rect x="368" y="0" width="32" height="512" fill="url(#warp_yellow)" />
It's not perfect, but it should give you some ideas. As you can see, it uses stroke="none" throughout - all the colouring is via fill=. --Redrose64 🌹 (talk) 09:48, 22 June 2020 (UTC)
Thanks for the idea of that approach, but it's unfortunately not the use case I'm looking for. The issue is that I'm not just trying to make a diagonally striped pattern, I'm looking to show the actual weave of the tartan. So if you scale it up, you would see the distinct step from warp to weft, not a smooth diagonal approximating the interaction.
I think I've figured out that I only need a weft pattern as a mask on the full weft threads, and then put the masked weft over the solid warp threads, but I'm still running into an issue with making that mask pattern. Can you see where I'm going wrong here?
<svg xmlns="" width="100" height="100">
    <pattern id="HR" viewBox="0 0 4 4" height="4" width="4">
  	  <rect x="0" y="0" width="1" height="2" fill="#000" stroke="none"/>
	  <rect x="1" y="1" width="1" height="2" fill="#000" stroke="none"/>
	  <rect x="2" y="2" width="1" height="2" fill="#000" stroke="none"/>
	  <rect x="3" y="0" width="1" height="1" fill="#000" stroke="none"/>
	  <rect x="3" y="3" width="1" height="1" fill="#000" stroke="none"/>
      <rect x="0" y="0" width="100" height="100" fill="url(#HR)" stroke="none"/>
This just shows up as a full 100x100 black box, so when I try to mask with it, I lose the whole weft. But when I display the pattern rectangles by themselves, it is the exact thread pattern I'm expecting in a nice 4x4 box. So it's not filling the large rectangle with the pattern for some reason. It did the exact same thing when I used the dasharray on a winding 4x4 path for my thread interaction:
<path d="M 0,0 v4 h1 v-4 h1 v4 h1 v-4" fill-opacity="0" stroke="#000" stroke-dasharray="2 2"/>
so there's obviously something I'm doing wrong in applying the pattern to the large rectangle, but I can't figure out what it is. VanIsaacWScont 18:06, 22 June 2020 (UTC)
Eureka! I've just figured it out. I needed to do the mask in white in order get it working, and I didn't have the patternUnits or maskUnits parameters, which messed things up as well. Thanks for the code for me to look at, Redrose. I don't understand those parameters, but their presence clued me in on a possible issue. Here's my working code for posterity if someone is running into issues with patterns or masks in the future:
<svg xmlns="" width="100" height="100">
    <pattern id="HR" viewBox="0 0 4 4" height="4" width="4" patternUnits="userSpaceOnUse">
  	  <rect x="0" y="0" width="1" height="2" fill="#FFF" stroke="none"/>
	  <rect x="1" y="1" width="1" height="2" fill="#FFF" stroke="none"/>
	  <rect x="2" y="2" width="1" height="2" fill="#FFF" stroke="none"/>
	  <rect x="3" y="0" width="1" height="1" fill="#FFF" stroke="none"/>
	  <rect x="3" y="3" width="1" height="1" fill="#FFF" stroke="none"/>
    <mask id="weft" maskUnits="userSpaceOnUse">
      <rect x="0" y="0" width="100%" height="100%" fill="url(#HR)" stroke="none"/>
  <g> Tartan pattern: K10 G5 R10 K4 R4 Y1 
    <line stroke="#000" stroke-dasharray="10 15 4 9 4 15" x1="50" y1="0" x2="50" y2="100" stroke-width="100"/>
    <line stroke="#080" stroke-dasharray="0 10 5 37 5 0" x1="50" y1="0" x2="50" y2="100" stroke-width="100"/>
	<line stroke="#F00" stroke-dasharray="0 15 10 4 4 1 4 4 10 5" x1="50" y1="0" x2="50" y2="100" stroke-width="100"/>
	<line stroke="#FF0" stroke-dasharray="0 33 1 23" x1="50" y1="0" x2="50" y2="100" stroke-width="100"/>
  <g mask="url(#weft)">
    <line stroke="#000" stroke-dasharray="10 15 4 9 4 15" x1="0" y1="50" x2="100" y2="50" stroke-width="100"/>
    <line stroke="#080" stroke-dasharray="0 10 5 37 5 0" x1="0" y1="50" x2="100" y2="50" stroke-width="100"/>
	<line stroke="#F00" stroke-dasharray="0 15 10 4 4 1 4 4 10 5" x1="0" y1="50" x2="100" y2="50" stroke-width="100"/>
	<line stroke="#FF0" stroke-dasharray="0 33 1 23" x1="0" y1="50" x2="100" y2="50" stroke-width="100"/>
VanIsaacWScont 19:54, 22 June 2020 (UTC)
OK, the image is apparently c:File:SVG Black Watch Tartan test file.svg but you seem to still be having difficulties, going by your recent post at c:Commons:Graphics village pump#Uploaded an SVG, but it just shows up as a green box. I myself had some difficulty with masks a few years ago - c:Talk:BSicon/Icon geometry and SVG code neatness/Archive 3#Lines in tunnel relates to this.
I'll have another try, this time using little squares instead of plain diagonals. I can tell by your code that we have what is known as a 2/2 Z-twill so your idea of a repeating 4x4 pattern is in itself correct. --Redrose64 🌹 (talk) 09:53, 23 June 2020 (UTC)
So it turns out the issue might not have been with the mask, although I did use the manual values from [1] to bypass that bug as well. It cost me a few bytes, but it definitely works. The main issue was a problem interpreting the stroke-dasharray parameter on all my <line>s. Apparently librsvg sometimes balks at spaces in dasharrays, but you can just replace them with commas. You can see all my attempts at tracking down the issues in the file history at File:SVG Black Watch Tartan test file.svg. Now to my next task, figuring out how to make a userscript for creating tartan images from sett patterns. VanIsaacWScont 05:39, 24 June 2020 (UTC)
I should have spotted that! --Redrose64 🌹 (talk) 19:06, 24 June 2020 (UTC)