Jump to content

Community Wishlist Survey 2023/Multimedia and Commons/Native SVG support

From Meta, a Wikimedia project coordination wiki

Native SVG support

  • Problem: SVG files are currently rendered out as PNG files on pages that use the image.
  • Proposed solution: Embed the SVG into the page output, only using PNG as a fallback on devices that don't support SVG.
  • Who would benefit: Readers on various devices when zooming in on the image within an article.
  • More comments: Currently SVG files are rendered out in a fixed resolution PNG file which, when scaled, suffers from the usual issues when zooming into a raster image. Embedded SVG (allowing clients/web browsers to render the images instead) would allow these images to be scaled infinitely with the only restriction being the client/browser.
  • Phabricator tickets: T5593 (see related tickets)
  • Proposer: —Locke Coletc 18:59, 23 January 2023 (UTC)[reply]


  • I wonder how worthwhile it would be to give users the option to forcibly use the PNG fallback for individual images if performance improvements are necessary, such as [[File:Example.svg|forcepng]]. -BRAINULATOR9 (TALK) 19:52, 23 January 2023 (UTC)[reply]
    We can't rely on that. If someone adds a 28MB SVG to the frontpage... there has to be some sort of technical protection against that. Also we have the problem with fonts not being consistent across browsers, so for that you also need some sort of processing before you can have files included (these are details which are already mentioned in the relevant tickets). —TheDJ (talkcontribs) 19:54, 23 January 2023 (UTC)[reply]
    Just a clarification. I think this wish is very much doable. But it's going to be a little bit more involved than 'just switch to the original svg'. Will easily take a few weeks of work. —TheDJ (talkcontribs) 23:48, 26 January 2023 (UTC)[reply]
    Huh? I'm talking about, if this proposal is implemented and SVGs default to being rendered as SVGs, then the option should exist to use the PNG format as a fallback. -BRAINULATOR9 (TALK) 18:16, 16 February 2023 (UTC)[reply]
    @Brainulator9: I understand what you're asking for, but is there a reason someone concerned about that couldn't just simply upload a PNG rendering of the SVG for such a use-case? I think @TheDJ and I are thinking of technical restrictions to (as TheDJ suggested) limit gigantic SVG files from being sent as-is. But if there's some edge-case where a PNG is desired, simply uploading a PNG and then the SVG source for future editors to make changes to as-needed would suffice, no? —Locke Coletc 18:41, 16 February 2023 (UTC)[reply]
    That could work, as long as the end users remember to update the PNG fallback alongside the SVG original. -BRAINULATOR9 (TALK) 02:01, 17 February 2023 (UTC)[reply]
    I definitely think there should be a cutoff for how large of an SVG we'd want sent to clients. For all SVG < 32KB *or* where the SVG is smaller than a PNG, I'd presume we just send the SVG. For situations where the SVG is larger than 32KB AND the PNG is smaller, then it might make sense to send the PNG still. 32KB is a purely arbitrary number, I'd hope we'd look at the existing average sizes of SVG files throughout the projects and do some data crunching to come up with a number that makes sense. —Locke Coletc 19:59, 23 January 2023 (UTC)[reply]
  • There's a script I used to test how native SVGs would work on Wikipedia... and they worked okay unless they were detailed geo maps with many tiny polygons, in which case large parts of the wikipage would stop rendering, text and pics. This is the code for your common.js: //mw.loader.load( '/w/index.php?title=User:Opencooper/svgReplace.js&action=raw&ctype=text/javascript' ); ponor (talk) 21:27, 23 January 2023 (UTC)[reply]
  • Why can't Wikipedia clean up svg pictures before uploading them to the server? There are resources with an open license such as SVGo. This will ensure the safety of this format of images. It is also possible to make a limit on the size of uploaded svg for example in 56Kb (talk) 12:07, 26 January 2023 (UTC)[reply]
    Limit the size of the SVG is not a good idea. Or at least if limited, should be some reasonable big number (at least 25-30 MB). I have some maps in svg that require details and easily go over 10-15 MB. Ikonact (talk) 08:33, 27 January 2023 (UTC)[reply]
  • It's will be awesome, because SVG is can contain not only vector graphics, but also animated and also interactive graphics. Although, it was a security and peroformace issuie if WP will embed every SVG image. Maybe, we need special tag or something for svg-images, that checked for issues to decide, embed this image into page or make png thumbnail.--Tucvbif (talk) 15:38, 11 February 2023 (UTC)[reply]
    I understood embedding SVGs to mean "using the original SVG wherever PNG thumbnails are currently being used". That being said, there's no risk of interactive graphics screwing with the page, as an SVG's code needs to be embedded directly into the page in order to respond to user activity. Moreover, this feature wouldn't introduce new security issues, as WP already blocks SVG uploads that contain scripts and other "problematic" content. Alhadis (talk)