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.
- A little flat-color icon? That’s clearly SVG territory.
- An interactive console-like game? That’s clearly canvas territory.
I know we didn’t cover why yet, but I hope that will become clear as we dig into it.
SVG is vector and declarative
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.
That makes logos a very common SVG use case. SVG code can go right within HTML, and are like declarative drawing instructions:
If you care a lot about the flexibility and responsiveness of the graphic, SVG is the way.
You put a
SVG is in the DOM
If you’re familiar with DOM events like
mouseDown and whatnot, those are available in SVG as well. A
isn’t terribly different than a
SVG for accessibility
You can have a text alternative for canvas:
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.
Canvas for pixels
As you’ll see in Sarah Dranser’s comparison below, canvas is a way of saying dance, pixels, dance!. That’s a fun way of explaining the concept that drives it home better than any dry technical sentiment could do.
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 (note the simple vector-y-ness of this game).
CSS can play with SVG
Note how I’ve put the