SVG and canvas are both technologies that can draw stuff in web browsers, so they are worth comparing and understanding when one is more suitable than the other. Even a light understanding of them makes the choice of choosing one over the other pretty clear. <\/p>\n
I know we didn’t cover why<\/em> yet, but I hope that will become clear as we dig into it.<\/p>\n <\/p>\n If you know you need vector art, SVG is the choice. Vector art is visually crisp and tends to be a smaller file size than raster graphics like JPG. <\/p>\n That makes logos a very common SVG use case<\/a>. SVG code can go right within HTML, and are like declarative drawing instructions:<\/p>\n If you care a lot about the flexibility<\/em> and responsiveness<\/em> of the graphic, SVG is the way.<\/p>\n You put a If you’re familiar with DOM events like You can have a text alternative for canvas:<\/p>\n You can do that in SVG too, but since SVG and its guts can be right in the DOM, we generally think of SVG as being what you use if you’re trying to build an accessible experience. Explained another way, you can build an SVG that assistive technology can access and find links and sub-elements with their own auditory explanations and such.<\/p>\n Text is also firmly in SVG territory. SVG literally has a As you’ll see in Sarah Dranser’s comparison below, canvas is a way of saying dance, pixels, dance!<\/em>. That’s a fun way of explaining the concept that drives it home better than any dry technical sentiment could do.<\/p>\n Highly interactive work with lots and lots of complex detail and gradients is the territory of canvas. You’ll see a lot more games built with canvas than SVG for this reason, although there are always exceptions<\/a> (note the simple vector-y-ness of this game). <\/p>\n We saw above that SVG can be in the DOM and that JavaScript can get in there and do stuff. The story is similar with CSS. <\/p>\n Note how I’ve put the We have a massive guide of SVG Properties and CSS<\/a>. But what is great to know is that the stuff that CSS is great at is still possible in SVG, like \n See the Pen Technically, they aren’t entirely mutually exclusive. A As Blake Bowen proves, you can even keep the SVG on the canvas very crisp!<\/p>\n \n See the Pen \n See the Pen Tablized from this tweet<\/a>.<\/p>\n Tablized from this tweet<\/a>.<\/p>\n Many folks consider scenarios with a lot of objects (1,000+, as Shirley says) is the territory of canvas.<\/p>\n A strong opinion, but it feels right to me:<\/p>\n One extremely basic way to answer it is "use canvas when you cannot use svg" (where "cannot" might mean animating thousands of objects, manipulating each pixel individually, etc.). To put it another way, SVG should be your default choice, canvas your backup plan.<\/p>\n — Benjamin De Cock (@bdc) October 2, 2019<\/a><\/p><\/blockquote>\n SVG is vector and declarative<\/h3>\n
<svg viewBox=\"0 0 100 100\">\r\n <circle cx=\"50\" cy=\"50\" r=\"50\" \/>\r\n<\/svg><\/code><\/pre>\nCanvas is a JavaScript drawing API<\/h3>\n
<canvas><\/code> element in HTML, then do the drawing in JavaScript. In other words, you issue commands to tell it how<\/em> to draw (which is more imperative<\/em> than declarative<\/em>).<\/p>\n<canvas id=\"myCanvas\" width=\"578\" height=\"200\"><\/canvas>\r\n<script>\r\n var canvas = document.getElementById('myCanvas');\r\n var context = canvas.getContext('2d');\r\n var centerX = canvas.width \/ 2;\r\n var centerY = canvas.height \/ 2;\r\n var radius = 70;\r\n\r\n context.beginPath();\r\n context.arc(centerX, centerY, radius, 0, 2 * Math.PI, false);\r\n context.fillStyle = 'green';\r\n context.fill();\r\n<\/script><\/code><\/pre>\nSVG is in the DOM<\/h3>\n
click<\/code> and mouseDown<\/code> and whatnot, those are available in SVG as well. A <circle><\/code> isn’t terribly different than a <div><\/code> in that respect. <\/p>\n<svg viewBox=\"0 0 100 100\">\r\n \r\n <circle cx=\"50\" cy=\"50\" r=\"50\" \/>\r\n \r\n <script>\r\n document.querySelector('circle').addEventListener('click', e => {\r\n e.target.style.fill = \"red\";\r\n });\r\n <\/script>\r\n \r\n<\/svg><\/code><\/pre>\nSVG for accessibility<\/h3>\n
<canvas aria-label=\"Hello ARIA World\" role=\"img\"><\/canvas><\/code><\/pre>\n<text><\/code> element, which is accessible<\/a> and visually crisp — unlike canvas where text is typically blurry<\/a>. <\/p>\nCanvas for pixels<\/h3>\n
CSS can play with SVG<\/h3>\n
<svg viewBox=\"0 0 100 100\">\r\n \r\n <circle cx=\"50\" cy=\"50\" r=\"50\" \/>\r\n \r\n <style>\r\n circle { fill: blue; }\r\n <\/style>\r\n \r\n<\/svg><\/code><\/pre>\n<script><\/code> and <style><\/code> blocks within the <svg><\/code> for these examples, which is valid. But assuming you’ve put the SVG literally in the HTML, you could move those out, or have other external CSS and JavaScript do the same thing. <\/p>\n:hover<\/code> states and animation! <\/p>\n
\n ExxbpBE<\/a> by Chris Coyier (@chriscoyier<\/a>)
\n on CodePen<\/a>.<\/span>\n<\/p>\nCombinations<\/h3>\n
<svg><\/code> can be painted to a <canvas><\/code>. <\/p>\n
\n SVG vs Canvas Scaling<\/a> by Blake Bowen (@osublake<\/a>)
\n on CodePen<\/a>.<\/span>\n<\/p>\nRuth John’s comparison<\/h3>\n
\n SVG vs Canvas<\/a> by Rumyra (@Rumyra<\/a>)
\n on CodePen<\/a>.<\/span>\n<\/p>\nSarah Drasner’s comparison<\/h3>\n
\n\n
\n \n<\/td>\n DOM\/Virtual DOM<\/th>\n Canvas<\/th>\n<\/tr>\n<\/thead>\n \n Pros<\/th>\n<\/tr>\n \n Great for UI\/UX animation<\/td>\n Dance, pixels, dance!<\/td>\n<\/tr>\n \n Great for SVG that is resolution independent<\/td>\n Great for really impressive 3D or immersive stuff<\/td>\n<\/tr>\n \n Easier to debug<\/td>\n Movement of tons of objects<\/td>\n<\/tr>\n \n Cons<\/th>\n<\/tr>\n \n Tanks with lots of objects<\/td>\n Harder to make accessible<\/td>\n<\/tr>\n \n Because you have to care about the way you anmimate<\/td>\n Not resolution independent out of the box<\/td>\n<\/tr>\n \n <\/td>\n Breaks to nothing<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Shirley Wu’s comparison<\/h3>\n
\n\n
<\/td>\n SVG<\/th>\n Canvas<\/th>\n<\/thead>\n \n\n \n Pros\n <\/th>\n Easy to get started<\/td>\n Very performant<\/td>\n<\/tr>\n \n Easier to register user interactions<\/td>\n Easy to update<\/td>\n<\/tr>\n \n Easy to animate<\/td>\n <\/td>\n<\/tr>\n \n \n Cons\n <\/th>\n Potentially complex DOM<\/td>\n More work to get started<\/td>\n<\/tr>\n \n Not performant for a large number of elements<\/td>\n More work to handle interactions<\/td>\n<\/tr>\n \n <\/td>\n Have to write custom animations<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n SVG is the default choice; canvas is the backup<\/h3>\n
\n