Recreating raster images as SVGs: part 1

Or, how to compress an image by 98% while getting a superior quality

Published Mon May 06 2019

Sometimes we do things for our clients and they have no idea what a huge benefit it is. We love doing things like this at ORB IT Solutions because, even though we don’t get credit for it, it elevates a final product to the next level. I’m going to share one of these techniques with you today, and hope it blows your mind 🤯. The technique is converting raster images to scalable vector graphic (SVG) images.

I hope to convince of you how utterly awesome SVGs are (for certain types of images). Then I’ll show you how to recreate a raster[^1] image as an SVG. We’ll use an image of an owl with a chevron background as our source. You can see what it looks like below:

Rasterized owl illustration

As you see, the image is primarily composed of simple shapes, making it perfect for vectorization. The SVG specification has shape primitives which account for a lot of the shapes we’ll be using here, along with the more general purpose <path>. For example, we’ll use <circle> and <rect> in our final image whenever we can, instead of the generated <path> which our a drawing program — iDraw[^2] — gives us.

In part 1 of this series I’ll give a high level overview of the steps I took to recreate the original image then show just how much we save by using an SVG instead. Part 2 will break down just how I arrived at my optimized SVG and launch into a short discussion of whether it was worth it.

Enough chitchat though, let’s get to work. Our owl above is composed of six shapes:

  • the body - oval
  • the eyes/toes - circles
  • the leg - quadrilateral
  • the wings - stretched oval
  • the ears/nose - deformed triangle
  • the feathers - circle + deformed lines

We also have a chevron background which is composed of a simple shape: rectangles.

The more complicated shapes were created from simpler shapes.

  • The nose/ears were made from equilateral triangles with anchor points dragged to create the slight curve on the sides.
  • The wings/hands were made from a circle with the bottom anchor dragged down to the desired point.
  • The feathers were created from circles and lines according to this raindrop tutorial.
  • The chevron was created as two pairs of rectangles at right angles (90˚), which was later rotated to 45˚.

That ends the image creation portion of our show. Here is the recreated svg image, you may notice I’ve taken some artistic license and subtly changed things. If I were doing this for a client’s logo I would, of course, make no changes.

SVG version of owl illustration

I exported my owl as an SVG and a PNG and the file sizes are shown in the table below. Before we get to that though, a little explanation is in order.

  • The Optimized PNG is a 256-color png, whereas the original has the usual 16 million or so colors.
  • The original SVG is the code, as given to us by iDraw. The optimized SVG has replaced the iDraw-generated code with the SVG primitives such as <circle> and <rect> where possible. It also uses <pattern>s[^3] and <defs>[^4] where possible.

Table 1. File size comparison between PNG and SVG owl image

@2x PNG PNG SVG Compressed SVG
Original file size 191K 75K 16K 5.6K
Optimized file size 54K 24K 5.3K 1.8K

From Table 1 we can see huge file size savings when comparing this SVG to the exported PNGs. It is clearly a win to use them if only to save on size. Another advantage it that because SVGs scale so well, if we need them at larger sizes, the image quality will not suffer from pixelation or bluriness[^5]. We also don’t need to create multiple assets @2x, @3x, etc to get this improved visual fidelity.

This ends up saving us time in the creation and testing process. I mean, how many times have you delivered assets, or had them delivered to you, only to realize that you don’t have the mobile version, or the retina version you need. Having one asset we can use for all devices saves us in the design, development and testing phases of creation.

I’m not even going to touch on other advantages of SVGs such as being able to change colors and add simple animations using CSS or Javascript. But the fact that we have the option of turning a static image into a moving one, given a few lines of code is a huge advantage over any raster image format. That’s another (in the pipeline) article for another day however.

Table 2. Percent difference in SVG file size compared to @1x PNG equivalent

File type Difference compared to @1x PNG
@1x PNG 0%
Optimized @1x PNG 68%
SVG 78.7%
Compressed SVG 92.5%
Optimized SVG 92.9 %
Compressed and Optimized SVG 97.6%

Table 2 takes a slightly different look at the data in Table 1, this time comparing % savings to the @1x PNG file. What we see here is that compared to our optimized PNG our SVG only offers us about a 10% savings in file size. Until it’s compressed. At that point our (still unoptimized) SVG is 92% smaller than our unoptimized PNG. This is huge and shouldn’t be ignored.

For better or worse, optimizing assets is a process that takes time. This is true whether we’re optimizing raster or vector graphics. By serving compressed SVGs, which is nothing more than a simple switch at the server level[^6], we’ve:

  1. saved our user’s data,
  2. saved our client’s bandwidth,
  3. provided a superior visual experience,
  4. which is also responsive.

All this was basically for free once the original image is created. Even if you don’t care about high resolution/retina displays you can benefit from using SVGs.

Table 3. Percent difference in SVG file size compared to @2x PNG equivalent

File type Difference compared to @2x PNG
@2x PNG 0%
Optimized @2x PNG 71.7%
SVG 91.6%
Compressed SVG 97.1%
Optimized SVG 97.2%
Compressed and Optimized SVG 99.1%

Table 3 shows us that there are even more dramatic file size savings to be had when comparing SVGs to @2x assets. At this point SVGs might not look better than @2x graphics (until we get to @3x displays) but all the other advantages still stand: smaller files, compressible, scriptable, animatable.

When we look at the compressed SVG it’s 97% smaller. The optimized and compressed SVG is 99% smaller. Now, one asset might not be a huge concern, but over multiple images, and multiple users downloading those images that size difference adds up.

Now we’re not just talking savings to users’ data, but a quantifiable difference in clients’ bandwidth and therefore the money the spend on that bandwidth. 191KB-16KB is 175KB. 175KB * 365.25 days * 100 users/day is just over 6 GB saved per year. Now imagine if your site get ~10,000 hits per day.

Let’s say you can convert all those social icons, all those text banners, all those call to action buttons[^7]. How much bandwidth are you saving? How much money are you saving your client now? How much time are you saving the user?

But it’ll cost too much to do it piecemeal?

Anonymous Client

Maybe. Perhaps it’s time to sell your client on a redesign. If you’re pointing out the real life benefits beyond just Ooooh, prettty! they’ll want to greenlight your next redesign pitch. Did you know google boosts your search page ranking based on how fast your page loads? It’s been happening since 2010.


You’re website or app will include multiple images. Users now expect the apps they use and websites they visit to look good on all their devices. The 5K iMac, the 4K TV, the Retina iPad, the Retina iPhone, the hiDPI Moto X, the Kindle, the Retina Macbook Pro. And we haven’t even gotten to the windows computers or tablets yet.

Instead of delivering piecemeal assets tailored to certain devices at @2x, @1x and now @3x resolutions we should look to using scalable images where ever they makes sense. Just as we should have moved on from using pixel measurements and pixel breakpoints, a tipping point has come where we should be looking at scalable images to deliver the kinds of visual experience our users have come to expect and our clients will be proud to deliver.

The take home message here is that whenever you have the option of using an SVG or PNG for use on the web, or even with your app (Yes. iOS and Android are both capable of rendering SVGs within native apps),seriously consider the SVG. That’s enough of me talking for now, I think the numbers speak for themselves.

Oh, and here’s the raw data used to generate the tables above. Nothing fancy here, just a list of files in a directory.

-rw-r--r--@ 1 username  admin    54K Jan 27 08:26 owl-256-orig@2x.png
-rw-r--r--@ 1 username  admin    24K Jan 27 08:25 owl-256-orig.png
-rw-r--r--@ 1 username  admin   191K Jan 27 08:19 owl-orig@2x.png
-rw-r--r--@ 1 username  admin    75K Jan 27 08:18 owl-orig.png
-rw-r--r--+ 1 username  admin    16K Jan 27 08:23 owl-orig.svg
-rw-r--r--+ 1 username  admin   5.3K Jan 26 22:46 owl.svg

Comments? Questions? Interested in talking to us about a project that can benefit from SVG-ification? Feel free to contact us today for more info.

[^1]: Raster images are generated at with fixed dimensions. Any upward deviation away from those dimensions will result in images with reduced quality (and visible pixelation). [^2]: iDraw is without a doubt the best vector drawing app I have ever used. I do all my vector work here despite having Adobe Illustrator on my mac. I highly recommend giving both the Mac and iPad versions a shot. [^3]: The <pattern> tag allows us to define a repeating portion in a <defs> tag which is used later. [^4]: The <defs> tag meanwhile, is a placeholder for bits of SVG code we’ll probably use multiple times. Instead of copying it multiple times in the same document, we can define it once, and reference it in one or more <use> tags later. It’s not actually necessary to place items which we will reference in <use> tags within <defs>, all that’s necessary, is an id attribute to reference. By using the <defs> tag, we are able to hide the snippet so that it’s not rendered until we wish to see it. Sometimes you might not want to hide first/use later, and so will just reference an id within a <use> tag. [^5]: There are, however, other issues to be cognizant of with respect to SVGs scaling on certain displays. [^6]: Even if you’re running you’re own server and using a somewhat complicated server such as nginx, telling the server to compress all text files (which is all an svg is), is such a simple thing you have no reason not to do this. [^7]: By the way why, in 2019, are we still accepting images as buttons?