News, insights and inspiration about customer engagement.


Practical SVG Usage

by Steve Schrab on December 21, 2011

Scalable Vector Graphic (SVG) files are nothing new; they’ve been around for years. Despite this, we still haven’t seen them used as broadly as they could be. Given that the goal today is to build increasingly responsive and adaptive sites that look great not only on high-res desktop displays but also in the palm of your hand on mobile devices, bypassing SVG is a huge oversight. SVG files shine in this area as they’re completely resolution independent and (typically) have a smaller file size than their bitmapped brethren. If you’re targeting an iPhone with a Retina display, do you really want to make 3G users download a bigger file just to take advantage of that screen? Why not scale a single SVG file without wasting additional bandwidth?

Comparison of PNG scaling versus SVG scaling

Comparison of PNG scaling versus SVG scaling.

Of course, SVG files aren’t appropriate for every image type. Photography is still in the realm of the JPEG, and many sites use photography as their main graphic elements. Where you don’t need photography, CSS3 is able to fill in a lot of gaps as far as design elements are concerned. So, then, where is SVG appropriate? How about one of the first elements to generally appear on a web page – the logo.

The logo

Many logos are already created in vector drawing programs, like Adobe Illustrator. Yet they’re often rasterized and placed on the page as a PNG or GIF file. Why not preserve their original precision?

Consider the following:

  • A brand logo is an ever-present element on your site and one that is found on every page. Spending time optimizing global elements is always time well spent.
  • A logo isn’t simply some random bit of chrome or graphical glitz. To some extent, it can be considered “content.”
  • If you’re into print style sheets, an SVG file’s resolution independence can make your site’s printouts look as good as your company stationary.
  • A logo is a key part of your website. It’s your brand. Your identity. Certainly it’s worth a little extra time and effort.

How do I do it?

In Adobe Illustrator you can save SVG files out directly. In the dialog box, choose the profile SVG Tiny 1.2., which is meant for devices with reduced computational and display capabilities. Sounds perfect for mobile devices, doesn’t it? Uncheck the "Include XMP" box (You have to click “More Options” first). Including the XMP data will add a lot of unnecessary metadata making your file size much bigger. Since this data is irrelevant on the web and we really just want the vector info, we can get rid of it.

Once you have your SVG file, you can link to it using image tags or CSS background images. Previously you needed to link them via object tags, but since we’re not looking to add any scripting or interactivity to our SVG files, linking them via a static image method should be appropriate. However, be sure to tell your server admin to set up a mime type for ‘image/svg+xml’ for your SVG files. It may not be set by default.

In your image tags, you can even set a width as a percentage to make your logo perfectly scalable with your responsive layout. You’ll find your logo looks great at all resolutions, with no multiple image swapping and still just a tiny file. Many of the logo files I've used in SVG format have ended up being as small as 2KB with gzipping. For example, the GS logo on the corner of this site.

What about browser support?

All modern browsers have good SVG support. Many have had it for quite some time. Internet Explorer has support as of version 9. Using a JavaScript library called Modernizr, we can easily test for SVG support and swap a vector file for a well-supported bitmap file. Just put Modernizr on your site, and it takes care of most of the work for you. You'll need to create a fallback PNG file, but by using these methods you can avoid the browser downloading both files.

For example, in CSS just use .no-inlinesvg and .inlinesvg before the selector with your background image.

.no-inlinesvg #logo {
	background: url('logo.png');

.inlinesvg #logo {
	background: url('logo.svg');

For image tags, you can use JavaScript to swap your files.

$(document).ready(function() {
	if (Modernizr.inlinesvg) {
		$('#logo').html('<img src="logo.svg" alt="Your Company" />');

	} else {
		//No SVG.
		$('#logo').html('<img src="logo.png" alt="Your Company" />');

<a href="/" id="#">Your Company</a>

While many browsers support SVG files, they don’t all support SVG use in IMG tags or in CSS backgrounds. For example, using SVG inline has only been supported in Firefox since version 4.0. So the venerable Firefox 3.6 would receive the PNG fallback in this case.

What is the payoff?

The mobile space continues to grow. Android and iOS both have devices with scalable high-res displays. Instead of making bigger high-res bitmaps that will inevitably have a larger file size, simply use a single small SVG file that will look great regardless of how large or small displays become.

On the desktop when you use browser zoom, your SVG files will scale just as flawlessly as your HTML text. What’s more, the latest version of Safari allows you to double tap with two fingers (assuming a laptop trackpad or Magic Trackpad) and zoom your viewport much like you do on the iPhone. Again, your SVG files will scale beautifully.

Speaking of Mac OS X Lion, there’s evidence that future versions of OS X will take advantage of high-res displays. You can scale the display up without changing your resolution. There's similar development within Windows 8 as well. While display resolutions are still not high enough to really justify this, you can see a day where we’ll have a Retina caliber display for our desktop machine.

With a combination of web fonts (for greater use of HTML-rendered text), CSS-rendered graphics (rounded corners, gradients, drop shadows, etc.), and SVG files, we can future-proof (or at least future-friendly) our websites by making them more resolution independent. Sure there are a number of steps beyond just linking to a file, but we can start with one of the single most important graphical elements on our site. The logo. It’s an element that will help you dip your toe into the manner in which we may be making websites in the future.



So what seems to be the general consensus around releasing "hi-res" (e.g., SVG) versions of artwork out into the wild? All the SVG dev/design articles I've read have only talked about the technical and visual benefits, but I've not read anything that explored intellectual property consequences. Imagine if every photograph online was actually a super-hires image that could be printed into large scale posters. Would photographers ever be able to sell their work? Would businesses like be out of business if they published previews of their artwork in SVG? Or am I an old man worrying about copyright protection in an open source world?

Good question! That is a difficult problem facing us in Internet land. Hi-res photography and graphics are going to become more and more desirable on websites as our displays start doubling in resolution. Right now that's only a problem for smart phone users, but by the end of the next year, you'll likely see these Hi-res display sneaking into tablets and some desktop computers.

This is already problem with embedded fonts. You can embed fonts on your web pages using CSS, but there is nothing stopping someone from downloading that font to their computer. So if you want to avoid legal issues, you either use free fonts from something like Font Squirrel or use a font embedding service like TypeKit which will protect your fonts from outside download.

As far as SVG icons, that might not be as bad as it seems. There have been services that have sold stock bitmap icons before and those are probably even easier to steal. I think companies that provide those types of graphics expect a certain amount of piracy. I would assume most professional agencies would respect the copyright of those creators and pay for their icons. Someone who made their own Doctor Who blog might not.

Photography gets a little more tricky. Large photographs prepared for hi-res displays are starting to approach a reasonable re-printability. The only thing I can think of is that a photographer should perhaps charge more for their services when terms of usage include web use? This might only apply stock-photo photographers, but who knows.

A bigger question is what happens when those photographs double in both resolution AND file size? Internet speeds haven't increased that dramatically over the past few years, so is it reasonable to expect they'll stay the same over the next few years? Possibly. What it means to me as a front-end developer is that we need to start using more HTML Fonts, SVG files, and CSS-created graphics for the interface of site in order to keep downloads small. That way when a user hits that 2000 pixel wide header JPEG, perhaps they won't notice your site slow down all of a sudden.

It'll be interesting to see how it all shakes out.

Have you had any success using a JavaScript library (like ) to implement SVG in non-HTML5 browsers (e.g., IE8)? Or does that overly complicate things? Am I better off using Modernizr to feature-sniff and fall back to bitmap images, rather than trying to force SVG?

Yes, we've used Raphael before. While there is nothing wrong with it, it is a 20K library when gzipped. So you need to balance the need with the extra download.

In our case, the SVG is being used as a static design element. So it's there primarily for hi-res displays. Since browsers that don't support SVG are unlikely to be used with a hi-res display, it seemed a safe bet that users on older browsers wouldn't notice they were getting a bitmap.

I used Modernizr for the sniff because it has so many other great feature sniffing... ah... features. Also it also provide HTML5 support for older browsers. Really a great library. I use in just about every site I make these days.

Now, if you're using SVG for more dynamic assets (charts, graphs, etc.) and you need those assets to display on older browsers, then Raphael works great.

SVG images can contain a copyright notice. Here is an example, the images shown all contain a copyright notice that is unseen. Yes, they can be copied, but if used on a commercial site legal action can be taken. The copyright notice can not be edited out because the images are in a uneditable WOFF font.


I wondered how some services protected their fonts? That's good to know.

On SVG the problem is that the copyright info can be easily changed or deleted since the format is in XML format. Which is a pretty easy for human readability.

However, I don't see copyright being a major hurdle for SVG as it's more of an "illustrative" format. A lot of it's use will probably revolve around logos and probably bits of "UI chrome" that can't be recreated using CSS. These elements will likely be pretty specific to the site design itself. So unless someone steals your whole layout, I can't see it being a major problem.

In your example, I believe you want to use "no-svg" as opposed to "no-inlinesvg" as your Modernizr test. It's my understanding that to inline svg means actually using the <svg></svg> code within your HTML as opposed to placing a reference to your svg file in an <img> or CSS background:url(mysvg.svg).

Here's a better page explaining the differences that I just found:

Actually, that's what I originally thought too. But I believe Modernizr uses a different terminology for this versus inline SVG elements. It's that terminology that had me chasing my tail and using much more complicated solutions than this.

Using .svg and .no-svg will only give you browser support for SVG itself. Not SVG use in "inline" elements like IMG tags or CSS background-image. Which is required to get proper detection for browser's like Firefox that have supported SVG files for years, but only started supporting "inline" elements around Firefox 4.

While an inline SVG is defined as putting the SVG elements directly into the HTML, I believe Modernizr is using the term inline-svg differently. And by "inline" in this case they mean the browser's ability to use SVG in IMG tags and background-image.

Or... I could be completely wrong on my understanding of what Modernizr means by "inline-svg." It could just be a happy coincidence that when Firefox started supporting inline SVG, they also started support the use of SVG in elements and that's why it works. If so it still makes this a valid case to test for.

I'm going to send the Modernizr team a tweet and see if they'll answer this for us. I'll update this post with any new info I find.

Add new comment