SEO Warp Blog

Return to SEO Warp

SVG Scaling Problems in IE9 and Other Browsers

Written by Nick on June 15th, 2011

Today we are performing SVG tests on the various major browsers to see why typical images don’t always get transformed or rendered properly.

SVG, or Scalable Vector Graphics, have been around since 1999, but are only recently becoming more widely supported in web browsers. Part of this is because of the anticipation for the HTML5 standard which allows for things like the <canvas> element, finally enabling website developers to draw using vector graphics directly on their web pages.

However, due to the number of variables that can alter the way an SVG file can be displayed, it’s no surprise that there can be inconsistencies between the way different browsers handle the images. Specifically in this post, I’m going to discuss SVG sizing on a page using HTML and how to fix a couple of common scaling problems between several popular browsers.

I’m basically writing this because I’m rather new to using SVG myself and made the decision to use SVG images for SEO Warp to maintain the quality of scaled images. I also wanted to practice using Inkscape, which is a fantastic tool, but at the time of this writing, many of the SVG files generated by it can lack certain parameters that browsers require in order to display images properly. So if you’ve been using Inkscape and are having problems with different browsers rendering your images correctly, this post can probably help you to solve your issues.

Before I begin, I’d just like to point out that on my test page, Internet Explorer 9 refused to display any of my SVG images on a basic HTML page until I declared the HTML4 strict or HTML5 doctypes. If you’re seeing the broken image icon in place of your images in Internet Explorer, consider adding the following to the top of your HTML document before the rest of your code:

<!doctype html>

I’m not sure why it’s necessary to do that in IE, but it’s not like declaring a doctype is a bad practice anyways.

The most common problems that I’ve seen with using SVG so far are that Internet Explorer tends to clip resized images rather than actually resizing them and that Webkit-based browsers such as Google Chrome and Safari will resize and stretch images in strange ways. Let’s take a look at both of these issues because they have similar underlying causes.


SVG Clipping Issue in Internet Explorer 9

Large HTTP 1.1 Icon

Large HTTP Icon for our SVG test



For this test, I edited the icon for my HTTP Viewer, making it four times as large as normal and adding a little green star to its top left corner.

This larger version of the icon is 256×256 pixels, but we’re going to use our HTML img tag to resize it to 64×64. Any standard browser can resize an image with the height and width attributes allowed in this tag, and since we’re dealing with SVG, this should be even less of an issue; SVG is meant to be scaled without having to lose any quality of the image.

Here’s what the SVG looks like scaled down to 64×64 in several different browsers:

SVG Sizing Comparison

Five popular browsers scaling our SVG image to 1/4th the size

It’s pretty obvious that one of these things is not like the other. So why did Internet Explorer 9 clip our image to 64×64 rather than just resize it? Let’s check out the SVG code using a text editor (my favorite by far is Notepad++):


SVG Code Header

SVG header for the image in this resizing test

What we can tell from this SVG header is that the image is clearly 256×256 pixels, as defined by the width and height attributes. But as it turns out, there’s another parameter that we’re missing that IE9 is looking for: viewBox.

While the width and height parameters set the size of the image, it is the viewBox that determines the viewport of the image, or what section of the image should be seen by the user at a given time. When this isn’t present for Internet Explorer 9, instead of resizing the image with the <img> tag, it will actually use the width and height to instead define the viewBox, thus clipping our image.

So let’s edit the code a little and include our viewBox:

SVG Header with viewBox

Our SVG header with the viewBox defined at the end

Here, you can see viewBox added. The parameters should be obvious to anyone familiar with plotting points on a graph:

viewBox="[Starting X Coordinate] [Starting Y Coordinate] [Ending X Coordinate] [Ending Y Coordinate]"

And in this case, it’s simply saying that the viewBox is the exact same size as the image. Now that we’ve added it, let’s take a look at how it renders in our browsers one more time:

Working SVG resizing comparison

Everything is looking good!

Great success!

Now that we have our Internet Explorer resizing issue out of the way, let’s see what can happen if we try rendering and resizing images with different SVG size parameters.


Common SVG Resizing Problems

Robot Icon

SEO Warp's robot icon

In this next test, we’re going to use modified versions of the robot icon that I created for in SEO Warp’s web crawler.

Here, we are going to take this image and plug in different values for our width, height, and viewBox parameters and see how the various browsers handle them.

The following two images have these different versions displayed at 64×64 pixels and 32×32 pixels with the HTML <img> tag’s height and width attributes respectively:

SVG Size Grid

SVG images scaled to 64x64 and rendered in different browsers

Smaller SVG Size Grid

SVG images scaled to 32x32 and rendered in different browsers

The SVG header parameters for these images are:

  1. height=”100%” width=”100%” … viewBox=”0 0 64 64″
  2. height=”100%” width=”100%”
  3. height=”64″ width=”64″ … viewBox=”0 0 64 64″
  4. height=”32″ width=”32″ … viewBox=”0 0 64 64″
  5. viewBox=”0 0 64 64″
  6. height=”64″ width=”64″
  7. height=”32″ width=”32″

It’s no surprise that Chrome and Safari display the images so similarly since they both use the Webkit rendering engine to draw their pages.

Here are a few things that we can tell from these tests:

How the SVG viewBox works

How the SVG viewBox works with your browser

The Webkit-based browsers Chrome and Safari require height, width, and the viewBox to display properly. If the width and height are either defined as something as useless as 100% or if they aren’t defined at all, these browsers will make a guess as to what the dimensions ought to be based on the points and shapes defined in the body of the SVG file. Because of this, images will tend to get squished as shown in tests #1 and #5 where the viewBox is defined, but the height and width are either useless or undefined.

Also in these Webkit browsers, if the width and height are set but the viewBox is not, the viewBox will be set to the width and height. This is why in test #2 the images are crammed into the upper left-hand corner: 100% gets converted to an actual number when the image is being rendered; we could have just told the rendering engine that the image is 4098×4098 pixels or something equally outrageous. In the SVG file, the plotted points are really small in comparison: the points for the corners that are drawing the robot’s head are defined somewhere around (16,55) (48,33). In this massive field that we’ve defined for our viewport, it’s no surprise that the image gets crammed into the upper left-hand corner.

Internet Explorer 9 seems to ignore the width and height in the SVG for the most part. It will start drawing out the image based on the plots of the shapes in the SVG’s body. The viewBox is used to define the boundaries of the image. Once IE has those, it will cut out the representation of the SVG and use that render for any HTML transformations.

The safest way to implement a basic SVG image is to set the height, width, and viewports explicitly and give them relevant dimensions, like in examples #3 and #4.

I hope this post has been helpful.

15 Comments so far ↓

  1. Howie Knight says:

    Thank’s for the post, I didn’t know about the viewBox property and just that knowledge helped alot.

  2. Michael O'Rourke says:

    Great post! Have you experimented with using CSS3 transforms on SVG content? Scaling works but Chrome/Safari scale poorly with jagged edges while Firefox does a great job. Your suggestions don’t seem to help with that.

    • Nick says:

      Hey, thanks! No, I haven’t played around with CSS transforms yet. That’s something I’ve been meaning to do. I’ll give it some experimentation and if I find out something else, I’ll be sure to share it. What sorts of things have you been developing that use CSS3/SVG?

  3. […] based browsers. Turns out you need to provide both – the viewport and the width + height. See this post for an excellent comparison of SVG content in the different browsers. Share […]

  4. “I’m not sure why it’s necessary to do that in IE, but it’s not like declaring a doctype is a bad practice anyways.”

    It should be essential practice as it helps tell the browser how to show the page. Never leave it off.

    • Nick says:

      Excellent point. Though, I thought that it was a bit strange that you needed to declare that specifically in order to use SVG images with IE!

  5. […] Auf bin ich auf diesen interessanten Artikel gestossen. […]

  6. Costa Michailidis says:

    Hmm… great post! I’ve followed your suggestions, in fact I had them all in place from the start, but I’m still not getting the scalling I need in IE9.

  7. Fritz says:

    I came across your post while searching for a solution to this svg problem which i logged on stacoverflow:

    In the proble outline example I do not use the viewbox attribute like your post suggests, but I have checked and adding it makes no difference. I was wondering if you have any suggestions?

    • Nick says:

      Hey Fritz, are you still having this problem? I don’t see the question on Stack Overflow, so I’m not sure what the details would be. Maybe try playing with the viewport sizes to see if that helps?

  8. Jussi says:

    Thanks for sharing the information about the viewbox parameter, it solved one of the many IE problems that I’m facing.

  9. Daniel says:

    Thank you!! It helped me a lot!