For the longest time, when we thought about the format of the images we wanted to use in our web projects and apps, we had a solid stable of choices to go with:
There is one more image format that has existed since 1999 that has been gaining a lot of attention only recently. That image format is the SVG, short for Scalable Vector Graphics. In the following sections, we’ll take a quick look at what SVGs are and what makes them something you should seriously consider using today.
Onwards!
At the most basic level, a SVG is just an image format like the PNGs, JPEGs, and GIFs of the world. What sets it apart is that it is a vector image format. There are several layers of detail we can go into here about what being made up of vectors means, but the most important one is that a vector image will fully retain its crispness no matter how far you zoom in. Take a look at the following SVG:
Notice that the image looks nice at its original size. It still looks nice when you enlarge it. Contrast this with what you would get with a PNG of the same image:
At its original size, our PNG looks identical to the SVG version. When enlarged, the difference is really noticeable. The larger version of the PNG is all pixelated and weird looking.
The reason for this stark difference has to do with the type of information each image format stores. A vector image format like our SVG stores drawing instructions on how to draw the shape. This means that, for any given width and height, the image is displayed appropriately since it is custom generated on the fly by our browser.
Our PNGs, JPEGs, and GIFs are known as raster image formats. In a raster image format, you are storing actual pixel data. This pixel data is not flexible. It is associated with a particular image size with each pixel position precisely mapped, so going to a larger size than what you originally started off with will look weird. It's kind of like taking a t-shirt and stretching it. It's not a good idea.
You may be wondering why this matters. Why would you ever want an image to be displayed at a larger size than what you designed it for? It has to do with our higher-DPI screens, especially the kinds you see on the large number of mobile and non-desktop/laptop devices:
On these high-DPI screens, even though your image is being displayed at the same dimensions you may have originally specified, it will be displayed using extra pixels because the pixel density is higher. With our SVGs, this isn’t a problem at all. The image will scale appropriately and display with its vectory crispness. With raster image formats, your images will appear blurry since the physical screen is asking for more pixel data than what the original image contains inside it. This is the same reason why many images you may see when browsing on your high-DPI Macbooks, Surface Books, iPhones, and high-end Android devices look blurry.
Now, there is a workaround for you raster fans who need to ensure your images look crisp on high-DPI screens. It's an ancient trick known as downsampling where you create/save your image with a larger dimension than what you need and scale it down when using it in your app:
Because you start from a larger image that you squish down to a smaller size, your pixel density is pretty high and your images will look good on everything from low-DPI screens to high-DPI ones. Why isn’t this a good enough solution? The reason has to do with file size. When you save a PNG, JPEG, or GIF, we mentioned that what you are saving is raw pixel data. When you are saving a physically larger image, you have a lot more pixels to deal with which ends up ballooning the final file size. With SVGs, since you are saving drawing instructions and not actual pixels, the size of the image doesn't come into play so your final image is always going to be crisp without any increase in file size.
SVGs are great. We get it. This doesn't mean we can use them all the time, though. Because a SVG doesn’t store actual pixel data, it is a terrible format for displaying really complex visuals like photographs, blocks of text, and so on because those can't easily be represented as a series of drawing instructions. Even if you do manage to create a SVG out of a complex photograph, the resulting file size will be massive when compared to a raster image format like a JPEG...or even PNG on a really strange day.
What SVGs are great for is displaying shapes and other visuals that can be simplified into easily constructable geometric-ish patterns. An example of this would be the minimal, modern icons that most of our user interfaces use these days:
As with all things, you should experiment and validate that an image displayed as an SVG meets your quality and file size goals. There may be times when a equivalent PNG or GIF may give better results, so always be open for some strange surprises here.
There is a lot more to SVGs than what we looked at so far, but this is a good overview (if I do say so myself!) that hits all the major points. There are many reasons why SVGs haven’t been very popular until, what seems like, recent times despite having been around in some form since before the millenium. Let's look at a handful of those reasons as way of wrapping this article up.
One reason is lack of compatible tools. Finding an image editor that could export to SVG outside of the relatively expensive Adobe Fireworks (RIP) or Adobe Illustrator was a challenge. Today most image and icon editors make exporting to SVG as easy as exporting to any other image format:
Second, browser support for SVG didn’t hit critical mass until only a few years ago. The biggest laggards in providing full support were the old Microsoft browsers which, at the time, were the browsers that everybody and their grandparents used. If Internet Explorer didn't support something, you might as well not even bother implementing it. Don't you miss those days?
Lastly, the crisp scaling powers of a SVG weren't really necessary in a world where there were no high-DPI displays. Until mobile phones and Retina-based displays really started kicking the display capabilities up many notches, everything was designed to run well only at 72dpi. In such a world, an image you saved for 72dpi displayed exactly as you intended on almost any screen that could run your web content. There was no need to think about ever-increasing pixel densities and other very modern problems.
Just a final word before we wrap up. If you have a question and/or want to be part of a friendly, collaborative community of over 220k other developers like yourself, post on the forums for a quick response!
