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.
Latest comment: 4 years ago1 comment1 person in discussion
The following is a list of common vector editors and suggested settings for compatibility. The user guide of your chosen program may also be valuable in troubleshooting.
Most modern browsers can render SVGs in view-only mode. It may be convenient to set a browser as the default SVG viewer, but you can also paste the file path into the address bar. Please note that even if your browser renders an SVG correctly, it may render differently on Wikipedia.
SVG documents are text files, and can be edited like any other text file. Specifically, SVGs are XML documents, which have special support in many text editors. One potential disadvantage to editing SVGs by hand is that previewing your changes is more cumbersome. A rudimentary solution would be to open the SVG file in a browser while working on it, and manually refreshing the document to see the result of changes.
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.)
OpenOffice.org 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 OpenOffice.org Draw.
SVG code replacement guide (executing replace all using Nedit regular expressions)
It is easiest to save entire slides from Powerpoint as svg rather than saving multiselected objects with right click / save as picture, because for entire slides the boundaries will be cropped to the size of the slide and the background will be set to white. To save slides as svg, use file / save as / browse / save as type --> svg.
If your slide has text, open the exported svg into Notepad and replace all the existing font-family specifications with font-family="Liberation Sans,sans-serif". This specification will make Wikimedia render SVG fonts similarly to how browsers render Wikipedia fonts.
Text can also get chopped up on export, which causes rendering and localization bugs. To fix this, search for all </text> tags and make sure the tag isn't embedded in another text tag that's on the same line of text. Most embedded text tags can simply be deleted; however, but if content needs to be subscripted or subscripted, then replace the text tag with a tspan specifiction. For subscripts, use <tspan font-size="smaller" baseline-shift="sub">. For superscripts, use <tspan font-size="smaller" baseline-shift="super">.
I've uploaded spreadsheets that automatically generate XML code for charts in SVG format.
Summary: You simply paste or enter your data into the spreadsheet, and specify image dimensions, number of grid lines, data ranges, font sizes, etc. The spreadsheets instantly and automatically generate a column of XML code. You simply copy and paste that code into a text editor and save as an ".svg" file. The spreadsheets produce lean SVG code, and should save you time in creating SVG charts. Though my original spreadsheets are written in Microsoft Excel, I've received reports that they also work if read into other spreadsheet programs.
Warming stripes — Accepts a single dataset and converts to SVG code portraying Ed Hawkins'warming stripes graphics. User chooses vertical or horizontal stripes; normal or reverse data ordering; or from a variety of geometric shapes (updated 17 May 2023). . . . . Click here to see examples of warming stripes embedded in different shapes.
Warming stripes bar chart — Accepts a single dataset and creates a conventional bar chart whose individual bars/columns are coloured according to Dr. Hawkins' warming stripes colour scheme. Alternate option: choose one colour for ascending bars and another colour for descending bars. (updated 28 August 2023)
Line charts — Accepts up to six datasets. (updated 30 August 2023)
Vertical bar charts (column charts) — Accepts up to six datasets. Toggle between clustered and stacked charts; user can adjust "Yfloor"—the Y level (usually=0) from which columns rise or fall; user chooses to keep or ignore negative input values. (updated 27 August 2023)
Horizontal bar charts — Accepts up to six datasets. Toggle between clustered and stacked charts; user can adjust "Yfloor"—the value (usually=0) from which bars extend; user chooses to keep or ignore negative input values. (updated 27 August 2023)
Scatter plots — Accepts up to five datasets. (updated 28 August 2023)
Pie charts — Accepts a single dataset of up to 36 items. (updated 17 May 2023)
Variable-width bar charts — Accepts up to six datasets; is like "Vertical bar charts", above, but user can choose different widths for different bars. (updated 27 August 2023)
Radar charts — Accepts up to six datasets. (updated 6 May 2025)
Converting text in an SVG file into paths (shapes) increases file size, prevents localization/accessibility features, and complicates edits/modifications down the line. It is therefore generally disfavored, with some exceptions, such as text-based logos. The Wikimedia text renderer can introduce bugs as its fonts may differ from browser fonts or SVG editor fonts, but following the guidance below should minimize these errors.
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". (This is because "Liberation Sans" has the same letter size as "Arial" [metric-compatible], so it is less likely to mess up the text flow.)
Group the text, create a copy, and convert the copy to paths. Then either:
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
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.
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.
Rendering anomalies may occur in thumbnail views if small font sizes are used. Declaring font-size="35" (or larger) appears to avoid this problem, depending on the pixel size of your graphic.
Fonts should be sized so that they look good as thumbnails on wikipedia pages and so they are easy to view on smartphones. Smartphones are how most people access wikipedia. Thumbnails are how most other people see images, as very few people click images and zoom them in to see them. Avoid using or creating images with fonts that are too small to be legible in thumbnail or smartphone views.
The font size that appears in a thumbnail is a combination of svg width, thumbnail width, and font size. To match wikipedia font size as a thumbnail, use font-size = (63/(your upright value))*((your svg width)/1000). For instance, if the thumbnail will be scaled up to thumb upright=1.35 and your image has svg width of 960, set font-size in the svg to (63/1.35)*(960/1000) = 44.8.
Transparent backgrounds are fine, but do not think your image will always be displayed on a light or white background. The wikipedia smartphone app, for instance, renders images on a black background, so if you show black text on a transparent background it will be invisible.
None of these checkers are foolproof, so it's wise to validate images. You can preliminarily validate images by uploading them to the shared, temporary-use ___location Test.svg, though other users may overwrite your image at any time.
To force refresh images in your browser use Ctrl+F5 (Shift-Reload on Mac), so that you see the latest upload and not cached image copies (this is necessary even on wikimedia upload pages).
On Wikipedia SVGs are interpreted by the librsvg-library to create PNG previews at different image sizes (to rasterize them). 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. Some issues are enumerated below, but be sure to test your SVG files before and after uploading them.
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.
The librsvg-library does not accept a stroke-dasharray parameter with values separated by spaces. Replace all spaces with commas to bypass this issue:
Example: replace stroke-dasharray="2 3 2 4" with stroke-dasharray="2,3,2,4"
Use href= alone, not xlink:href=, in <use ___/> statements
xlink:href was deprecated and replaced by href in SVG 2, released in 2018. Between 2023 and 2024, Wikimedia's SVG renderer has been updated to follow suit, so xlink:href no longer works. Instead, href should now be used.
CSS selectors or identifiers must start with a letter or hyphen
If a black box appears, 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-command, or with Inkscape-GUI or with a Inkscape-batch), but to stroke the text using "object to path", since path-text is not recommended and increases file-size.
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.
Though Web browsers cope with image tags without width and height specified, librsvg ignores such images.
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.
Latest comment: 21 days ago10 comments4 people in discussion
G'day from down unda – I’ve hit a wall trying to export and upload an SVG diagram created in Draw.io (diagrams.net) for use on Wikimedia Commons. I’ve followed all documented best practices, but the UploadWizard either rejects the file, renders it blank, or errors out with “empty file” or preview issues.
This is a clean, historically sourced SVG showing the genealogy of the Australian Cattle Dog, and I’d like to include it as part of a breed lineage article. The file was originally constructed in Draw.io and exported as both `.drawio` format and `.xml`.
UploadWizard reports **“empty file”** or fails silently
Inkscape opens the file fine, but Commons rejects it
Upload preview fails — image does not render server-side
Draw.io adds problematic content:
Default SVG export includes `<foreignObject>` tags and the `http://www.w3.org/1999/xhtml` namespace, which are not supported by MediaWiki’s librsvg renderer
Even after disabling “Include a copy of my diagram”, and unchecking “Compressed”, Draw.io inserts XHTML wrappers when formatted text or word wrap is enabled
Manual cleaning attempts:
Removed all `<foreignObject>` and stripped metadata using Inkscape and SVGOMG
Attempted plain-text conversion, but doing so broke label layout and connector alignment
Used Python to decompress base64-encoded XML embedded inside the file, but the export appears truncated or malformed – resulting in either empty output or a zlib decompression error
Re-exported in every Draw.io combo: “Formatted text” ON/OFF, “Word wrap” OFF, “Compressed” OFF – still fails to produce a Commons-safe SVG
Help extract or reconstruct this diagram in a Commons-compliant SVG form?
Or confirm if the diagram can be converted without losing its structure or requiring a full redraw?
This file follows all Wikimedia SVG instructions as far as I can tell — but something in the encoding/export pipeline is throwing the UploadWizard off.
@Nodocéphale: I can't read the .drawio file that you link. Can you post a link to a screenshot, so we can get an idea of the intended content? (Maybe it will be easier to get someone to start from scratch, etc.). —RCraig09 (talk)18:07, 4 August 2025 (UTC)Reply
I was able to view the draw.io file linked above as text but although it looks like xml it looks nothing like svg. Was it created through the draw.io "Export as SVG" command? If not, where is the svg file that was created in this way? —David Eppstein (talk) 18:16, 4 August 2025 (UTC)Reply
FYI: I can view the file on the file description page, but when I click on it, the text doesn't show up (in Chrome 138.0.7204.169). ——RCraig09 (talk)23:08, 4 August 2025 (UTC)Reply
User:cmglee Thanks again for the incredible help so far — it’s much appreciated. Just one small flag: the second version of the SVG renders without any visible text, which might throw off random readers keen to understand the ACD lineage — just anticipating. The first version shows the structure clearly, while the second looks like a hiccup — text off the grid, so to speak.
I totally get that this is my project, and I don’t want to add any extra work on your end — but would it be of interest if we had a Commons-safe SVG where:
text displays correctly,
image elements are clickable,
and the whole thing can be dissected or iterated upon by others?
Happy to do the grunt work myself — just wondering if pointing to a working “debug” SVG (with full text and links intact) might help anyone else down the track.
@Nodocéphale: I don't understand what you mean by second version. I see only one version on commons:File:ACD_Origins_3-0-drawio.svg. Indeed, when the SVG is opened directly, the text is absent on Chrome (looks fine on Firefox).
@Nodocéphale: Why is it necessary to view the SVG directly in a browser? Won't an rsvg-rendered PNG thumbnail do?
Re my previous comment, I was mistaken; text is missing in Firefox too, as the SVG uses foreignObject instead of text tags. Strange that rsvg supports them.
http://drawio.com/doc/faq/svg-export-text-problems explains it and gives some workarounds. As I couldn't find Text Settings: in the SVG export dialog, I exported as PDF instead but the chart was haphazardly spread across multiple pages.
I next opened File:ACD_Origins_3-0-drawio.svg in Inkscape, saved as a PDF, closed it, opened the PDF and saved as a plain SVG. I found that all but one of the images missing, and the text converted into embedded PNGs.
Doubtful that I can proceed further besides redrawing the whole file, I'll leave this issue for someone else to pick up.
All good mate, working with InkScape now. That wizard seems happy with exports with text. Reopened the svg in there without any text at all, and rebuilding the file from there. In the future, if one there is, if the plan is to upload on commons, I will steer clear from Drawio unless they solved the problem depending on their marketing targets. Will post it in here for a technical review and then will make my way to the Teahouse so we can check policy and formatting. Now just saying, InkScape is very complex and missing the easy to find features from Drawio. Nodocéphale (talk) 01:08, 6 August 2025 (UTC)Reply
Latest comment: 4 hours ago3 comments2 people in discussion
Risley prism scan pattern
I made an animation of the scan pattern of Risley prisms. However, the thumbnail looks very bad. Can someone figure out how to make the thumbnail look nicer? I understand that we can't have animated SVGs in the thumbnail, but at least, it should look nice. The Python source code used to generate the animation is in the file page. dllu(t,c)03:27, 27 August 2025 (UTC)Reply
Consequently, the path is drawn as a dashed curve, the stroke-dasharray value of 1000 making each dash 1000 units long followed by a gap of 1000 units.
To work around the behaviour, one has to measure the length of the path (or eyeball it by trying out various values and doing binary search), and set stroke-dasharray, stroke-dashoffset and from in the animate tag to that value.
Regardless, the SVG is excessively large at 3.84 MB. Can you reduce the number of points and their decimal places?
Thanks, I reduced the file size 10x with a shorter path and fewer decimal points and I measured the path length exactly in my Python script. Cheers! dllu(t,c)20:33, 27 August 2025 (UTC)Reply
Latest comment: 5 hours ago1 comment1 person in discussion
Hi SVG experts,
I've just learnt that setting dominant-baseline:central is a better alternative to using y="0.7ex" or dy="0.7ex" to vertically centre text labels. According to http://www.w3.org/TR/SVG11/text.html#BaselineAlignmentProperties , it's in SVG 1.1 but when I used it in the first version of File:Nicomachus_theorem_2D.svg, our rsvg ignores it. Can someone please confirm if it's really unsupported or did I do things incorrectly?
.svg)
