By Craig Buckler

7 Reasons to Consider SVGs Instead of Canvas

By Craig Buckler

The HTML5 canvas element is used everywhere. From WebGL games to some amazing browser experiments, web developers are jumping on the canvas bandwagon and enjoying the ride.

But are we always using the right tool for the job? In many cases, Scalable Vector Graphics (SVG) offer a better alternative but it’s easy to forget about the technology when it’s hidden beneath the wave of canvas hype. If you’re not considering SVG, perhaps the following reasons will make you think again…

1. SVGs are Scalable

That should be obvious, but it’s a huge benefit — especially now people are using high-resolution iPads and monitors. It’s also a bonus for responsive designs and your logo or chart can scale accordingly.

2. Designer Tools

Canvas is a programmable image. Even importing a static graphic requires JavaScript and it’s certainly not possible to define animation or effects without delving into code.

But anyone can create an SVG. Many of the tools are free and offer custom animation facilities. Have a play with:

3. Language/Framework Support

Canvas elements are manipulated using client-side JavaScript. You can do the same with SVG but you can also create partial or complete images in advance. In addition, SVGs are simply XML; you can create or modify them using any server-side technology.

4. Browser Support

SVG and canvas elements are supported by all the HTML5 browsers. Neither have native support in IE8 and below, but shims such as Raphaël are available.

While that’s not necessarily a case for choosing SVG over canvas, you certainly can’t reject SVGs on the basis of browser support.

5. Accessibility and SEO

SVGs are accessible: text remains text, and something should appear even when your browser doesn’t support every element.

Humans and machines can understand SVG code even if they can’t render it. Search engines such as Google already parse SVGs but canvas elements will always require a fallback.

6. DOM Handling

SVGs have a DOM so it’s easy to attach event handlers and manipulate elements like you would for other HTML block. To move an item you simply change its co-ordinates.

The same is not true for canvas. To determine whether your mouse cursor is over an object, you need to compare the two locations and react accordingly — perhaps re-drawing the whole of the canvas again.

7. It’s More of What You Know…

SVG is XML and uses tags just like HTML. It also supports CSS, webfonts, and the JavaScript techniques you’re familiar with.

Canvas manipulation isn’t difficult but it requires a different mindset and you’ll need to learn the API.

…and the Future Looks Bright for SVG

The technology may have been around for more than a decade, but SVG developments continue to advance. Browser vendors are adding support for CSS backgrounds and inline integration as well as implementing mobile engines, animations, transforms and filters.

Canvas is also evolving but it remains a self-contained programmable bit-mapped image element. That will always impose limitations.

The Downsides

SVGs certainly aren’t necessarily the best solution in all situations. If you’re animating hundreds of items — perhaps for a firework or explosion effect — canvas will always be quicker because it’s not constrained by the number of DOM elements the browser can handle. Canvas will generally be the best choice for fast action games.

In addition, SVG performance isn’t always perfect and the webkit engine seems especially poor. You can often see Chrome and Safari redrawing each element in turn and, although they support animation, you can’t apply SMIL nodes to the SVG DOM with JavaScript.

However, SVGs remain a better alternative for logos or charts with fewer intensive effects. They’re not as trendy as canvas but that’s no reason to avoid them.

Look out for some new SVG tutorials on SitePoint soon…

  • hello, im testing html 5 lot of time ago, and CANVES is the best, i dunno why to compare him with the evil xD i love canvas, is simple but powerfull !

  • You seem to have bought into a lot of the myths and lies about Canvas.

    1) scaleable… So is canvas since the CANVAS element’s physical size in pixels is unrelated to the units used internally to draw with. canvas.width is virtual coordinates and are render coordinates… if you set canvas.width=320; canvas.height=240; then set’1280px’;’960px’ — you do moveto(0,0); lineto(200,200); on screen you’ll get a 4px wide anti-aliased line from 0,0 to 800,800 that’s smooth; because it’s scaled up the numbers automatically when rendering.

    If that’s not scaleable, I don’t know what is. It’s also why you have the SCALE function that can accept rotation and zoom, so that it’s number system internally is scaleable as well!

    2) tools — I don’t find SVG in any of those easier than code. YMMV.

    3) language/framework — becuase you can’t make client side code server side… because you can’t make sub-functions for each sub-primative of a complex object… Not sure what your point even was there.

    4) Brower support — SVG support is actually not as good as Canvas; what with Opera only implementing tiny.

    5) Acessibility — Uhm, not sure where you’re getting that a linked in XML file is accessible via the markup… and I though that’s what the content of a canvas element was for; when there is nothing rendering — of course content swap or element swap to add the CANVAS tag for graceful degredation makes SVG look like amaturish rubbish.

    5-2) DOM handling (you do know you’ have 5 twice, right?) … unless I missed something in SVG, it’s a pathetic toy in terms of user interaction compared to Canvas.

    6) More of what you know — if that were true people would actually be able to use SVG; fact is it’s an overcomplicated mess that few people are willing to take the time to figure out. There’s a reason the original champion of SVG — ADOBE — dropped it like a hot potato when

    7) The future — looks about the same as it’s past; an also ran that makes anyone who knows about doing graphics as code shudder worse than postscript. It’s been a promised future format and way of doing things for longer than CSS has existed, and to be frank, the majority of people could give a flying purple fish.

    Which is why CANVAS exists in the first place! One of the few things I like from HTML 5 — NOT that it has anything to do with HTML 5 or should even have a HTML element.

    SVG is a failed experiment from the late 90’s that even it’s creators want nothing to do with. It’s actually kind of a laugh that ten years after Adobe put it down like old Yeller, that anyone is even bothering to try and promote it again and that there’s actually support for it in some browsers.

    When really it should probably go the way of the dodo alongside other concepts like XML applications.

    • 1) Vectors are resolution independent. Bitmaps (and canvas) are not. You cannot resize pre-drawn canvas elements and expect a good result. At best, you’d need to redraw it again.

      2) Anyone can create an SVG. Only programmers can handle canvas.

      3) You can generate SVGs on the server as well as the client. Or you can create them in a graphics package. That’s a huge advantage in many situations.

      4) There was one reason why SVG never took off as it should: Internet Explorer. That’s become less of a problem now it’s supported in IE9 and 10 (and very well, I may add). I’m not sure why you consider Opera’s support to be poor either? If anything, webkit is the worst.

      5) Google can index SVG files but you can still offer fallbacks if necessary.

      5-2) (apologies – I can’t count). What user interaction does canvas have? You attach events to the whole canvas element. In SVG, you can attach them to individual elements such as lines, circles, polygons etc.

      6) and 7) Again, I put this down to legacy IE support. Adobe dropped their IE plug-in because no one installed it. But SVG is now a first-class HTML5 technology, all modern browsers support it (including mobiles), and I suggest you look at the specs to see what’s coming.

      Canvas is great and has its advantages but it was never a replacement for SVG.

      • 1) ‘redraw it again’ oh noes, making JS detect resize at worst and calling the same code again.

        2) “anyone” — I find SVG much harder to work with; I imagine I’m not alone on that. Take just trying to make a quadratic curve; where SVG uses relational coordinates meaning you can’t even moveto a endpoint and have to do all the math yourself. Pain in the ass. Excuse me if I’m not finding the difference sufficiently difficult to call SVG any less complex. If anything the need to restate stroke, width and fill on EVERY operation makes SVG painful to use at best. It either NEEDS some form of stylesheet to get rid of the endlessly pointlessly redundant code that makes HTML 3.2 look good, or to take a page from CANVAS and become state based.

        I want to draw three blue curves in a row I shouldn’t be making XML that looks like the peak of the browser wars. Oh wait, that’s when it was invented… Of course it being a darling of the HTML 5 crowd only further proves what a trip in the wayback machine this entire “future” of the Internet is. If this is the future, I want nothing to do with it as it sucked the first time around.

        3) and you can’t make a server output .js instead of XML? PLEASE. That’s a lame excuse at best, outright BS at worst.

        4) See my other new post here… Microsoft and Adobe worked together to make SVG and had support for it 6 years BEFORE FF or Opera did via an activeX plugin. It was kicked to the curb when Adobe bought Macromedia.

        5) … and that’s different from what goes inside the CANVAS tag how exactly?

        5-2) Trap the mouse and read it’s coords… if a few comparison operations are a deal breaker…

        6-7) then you mention exactly WHY prior to HTML 5 I’d have called it dead.

        It’s a fat bloated dead end technology… and I’ve tried it recently, if anything it’s gotten worse now that the W3C has been running with it… Must be the WhatWG … folks… messing with it; It’s another of the HTML 5 stupidities that honestly makes me have ZERO interest in said specification…

        Figures, by the time SVG is implemented, it’s so horribly dated I can’t believe anyone wants to use it.

      • Are we talking about the same things here?…

        1. You don’t need to do that with SVG. And would canvas always be easy to redraw? Only if you’re keeping track of every item and have no random effects.

        2. You find it hard to create an SVG in a graphics app?

        3. You’re seriously advocating writing canvas-creating JavaScript with server-side code? I thought that practice died out years ago. The point I’m making is that it’s easy for server-side code to generate XML or pass a static SVG.

        4. Do you really care what Adobe did or didn’t do 13 years ago? SVG is finally supported by all browsers whether Adobe like it or not.

        5. Google can’t index content on a canvas element or any JavaScript code.

        5-2. And how is that better for user interaction (as you originally stated)? With SVG you can attach an event handler to a 1px line angled and moving in any direction – try doing that well in canvas using one line of code.

        6/7. So you considered SVG dead prior to HTML5? Fine — what about now?

        I’m amazed you can call SVG bloated. XML may not be the most efficient data format but you still have the advantage of vector output. If you don’t like the schema, submit your suggestions to the W3C.

        Finally, no one’s saying you shouldn’t use canvas or SVG is always a better option. They’re different technologies — both might be viable in certain situations, but neither is a replacement for the other.

  • Xolani

    @Pura the author has not compared canvas to svg nor has he suggested that one is better than the other. However he merely states that “There are occasions that you might want to consider using SVG”.

  • kaf

    They are different tools for different purposes. I use SVG when flexibility is needed (most things) but switch to canvas when performance is needed. ie, SVG for graphs, Canvas for particle effects and other cpu intensive animations. Suffice it to say I mostly use SVG.

    Raphael makes life easy too. BTW Craig Raphael is not a shim, its a framework. Is JQuery a shim?

    • Raphael is a framework, but it also implements an SVG shim if you’re using IE8 and below.

  • snowman

    This is a very important article but it’s appalling that there is actually a need for it, it’s unbelievable that this HAS to be explained in this day and age.
    There have always been two different ways to define graphics on a computer: using a bitmap grid and vectors (isn’t this taught in elementary school?) each has its advantages and disadvantages, there’s always been software to manipulate each kind of graphic, but somehow people adopt the wrong kind of application or technology for a given task just because of the hype. There’s tons of examples, like Photoshop for web graphics, Fireworks to generate HTML, Flash for banners, animated gifs for video clips, touchscreens for keyboards, etc.
    A professional should know which tool to use, out of the requirements of the project, as a result of an analysis of all the factors in play, not of hype or his own limitations.

  • There is actually another way use SVG images, that is a normal img tag that points to an svg file. This way you get lot of the benefits of scalable images with little extra work. Browser support is the same as support for normal SVG.

    Combined with css transitions it also easy to move the images around. Unfortunately transitions are not very smooth outside of webkit browsers.

    • You can put SVGs in a normal image tag and it’ll work most of the time. However, there are situations when it doesn’t work perfectly in all browsers, e.g. when it has a linked CSS file. For the moment, the object tag seems more reliable.

  • Alex

    Well put arguments, Craig.

    With SVG working in CSS backgrounds, I think it’s a perfect complement to CSS.

  • JZA

    I always wondered if it was possible to do a complete site on SVG a few years back. It would be great to have a site reference similar to ZenCSSGarden – ZenSVGGarden? that showcase the power of SVG.

    • You can and I’ve seen a few experimental sites which have done that. However, use the right tool for the job – defining page text in HTML has far more benefits.

  • Tanios Kahi

    About browser support, unfortunately the android’s browser does not support SVG.

    • It does from v3. Opera and iOS have had it for a while.

  • The comments of deathshadow and Pura Salud are why those articles are needed.

    SVG is not better than Canvas and Canvas is not better than SVG. Unfortunately there way to many incompetent developers who chasing buzz words without understanding what is going on.

  • digitaldave


    You make a few valid points about SVG but honestly it has its uses like anything. You seem to be such a fanboy of canvas that your not willing to give other approaches to development a fair shake. SVG does have better accessibility then canvas because its text can be used for the visually impaired and be converted to other languages without any additional code. Your method for scalability is hack and will distort all your bitmap data, that would never get passed any creative teams I have worked with.

    Most of your other points are valid …

    • … and using bitmaps in SVG is different how exactly? Oh wait, it isn’t. Comparing bitmaps in canvas to vectors in SVG is like comparing diesel in an economy car to gasoline on a tractor-trailer rig. Vector to Vector, Bitmap to Bitmap; if there’s enough difference for it to be a worry, then the “creative teams” are in the wrong job; well, that or just aren’t willing to accept the realities of deployment for the web… but you said that with “creative team”.

      … and don’t think I’m a fanboy of canvas per se; we could use something better since Canvas is still a bit too complex for it’s own good with the whole context BS, and that it seems to have a HTML element for no good reason…

      We could use something better; fourteen years of watching SVG flounder about like a drunk slipping in it’s own vomit pretty well proves that it’s not the one.

      • DigitalDave didn’t mention anything about using bitmaps in SVGs. What point are you trying to make?

        But you still appear to be rejecting the benefits of vector over bitmap. When used appropriately, SVGs are infinitely scalable and have a far smaller file size than equivalent bitmap graphics. Inherent SEO and accessibility are thrown in as a bonus.

        And I don’t understand why you think SVG has been floundering? Why would Microsoft (finally) implement the technology if it were dead?

      • @craig — To paraphrase Chris Tucker: “Do you understand the words that are coming off of my keyboard?!?”

        That he didn’t mention bitmaps in SVG was EXACTLY my point; they behave the same in either.

        Canvas is drawn using a coordinate system that is INDEPENDENT of the display resolution; if your canvas coordinates are larger than the render area, it behaves much like SVG on scaling down; admittedly it doesn’t scale up as nicely, but as a ‘for web’ technology is it that hard to design large and deploy small? I think not.

        … as to floundering and Microsoft “finally” supporting it, you can use SVG in IE as of 1999; thanks to Adobe — the original champion of SVG who back then claimed they would kill off flash with it, dropped it like a hot potato, and buried said plugin deeper than most archeologists are willing to dig…. all the moment they bought out Macromedia.

        Though that’s business as usual for Adobe; can’t compete? Buy ’em out and either bury your own project (Flash vs. SVG) or just bury what you bought. At the time of acquiring Aldus, Photostyler blew the crap out of Photoshop — in many ways it still does… any trace of it’s code is long buried; that they got Pagemaker as part of the deal and could stop pretending Acrobat was a DTP helped too.

        Of course, these days it seems as if it happened before FF 1.5, it never happened. SVG was a joint venture between Microsoft and Adobe at the start; it’s why the first deployable web support for it was an Adobe plugin for IE 5 in 1999! That’s six years before Opera added support for Tiny or FF added support for 1.1!!! It is a mashup of VML and Postscript in a XML namespace… and who originated VML and Postscript?

        Adobe and Microsoft! Both companies kicked it to the curb about the same time other browsers started adding support for it; the same time Adobe bought Macromedia and by extension Flash. 2005.

      • @Jason – To paraphrase me: “no, I don’t understand your point!”

        To state SVGs are crap because embedded bitmaps aren’t scaled well is like saying MS Word is crap because people write trashy novels.

  • SVG is not better than Canvas and Canvas is not better than SVG. Unfortunately there way to many incompetent developers who chasing buzz words without understanding what is going on.

  • Thanks for a very interesting article. The statement, “You can’t apply SMIL nodes to the SVG DOM with JavaScript” is incorrect however. It is certainly possible to dynamically add animation elements to the SVG DOM with Javascript to trigger new animations.

    • Are you sure? The article states that it’s not possible in the webkit browsers — Chrome and Safari (and IE9 for that matter). As far as I’m aware, it’s a known issue. Do you have a working example which dynamically adds animate nodes to an SVG DOM and works in all browsers?

  • Andrew Simpson

    Hi, good article. Enjoyed reading it. If I am updating the Src of an IMG in a Javascript timer on an interval of 200ms would I be better of using Canvas? Thanks

Get the latest in Front-end, once a week, for free.