SVG vs PNG

[RichardKYA]

Hello,

I'm fairly new to code, been learning for less than a year, so sorry if this is a dumb question.

Why do developers/designers still use png instead of svg?

With svg being infinitely scalable and with retina screens, why do designers still spend time creating twice as many png icons, etc?

Far as I can tell, you can create svg sprites and use them in the same way as a png sprite, so you would only need to create one, instead of having to create 2 (one for retina and 1 for non-retina)

Is there a reason that png is still widely used today?

Anyone here use svg over png? Have you run into any problems?

I know inline svg isn't something that is greatly supported and from what I've read, there are issues doing it that way. Personally, I am more concerned about using svg sprites in the same way as you would use a png sprite, as this is what I am doing on my site and I haven't had any issues yet and hence why I am asking this question.

If you're doing something that seems flawless, but no one else is really doing it, then you start to wonder why lol

Thank you

 

[Daniel Hood]

This isn't the top answer on the page, but I think it's the most detailed and makes the most sense.

Which format is better for saving images intended for websites; PNG or SVG?

The simple answer here is use both.
The fact that you've named SVG as an option, means we can rule out photo graphics as an intended use case - because SVGs are only good for line-art graphics such as logos, icons and clip-art-like illustrations.

If you are considering this choice for photo graphics, there is no choice; PNG will probably always be better. For graphics where SVG is a viable option, SVG is the best option with a PNG/JPEG fallback. PNG has many strengths, but on scalability and file size, it will often not match up to SVG.

Using only one or the other means you will have to sacrifice either backwards or forwards compatibility.
Weighing them against each other, PNG certainly will be supported by more browsers than SVG at this current point in time, but the resolutions of newly released devices are forever increasing, meaning PNGs will either need to be served based on a wide variety of different resolutions (via Media Queries, JavaScript or User Agent Sniffing) or scaled by the browsers, which could produce some imperfect results.

Looking at what we know the future holds; forever higher resolutions, wider support and wider use of SVGs across the internet; it makes sense to build for what's coming.

In general, websites should be built to last for many years; in 5 years time your beautifully backwards compatible website might look amazing for the 2% of internet users still using old browsers, yet fairly poor on the up to date browsers with crazy resolutions - so it's very much a stack of hard choices on which way to compromise.

Your options in November 2014

1. PNGs only
   
   • For the sake of quality you'll need to serve at least five different versions depending on screen sizes and resolutions - and that's a very conservative guesstimate, you could end up with 10 - 15 versions of the same image if you wanted to be extremely thorough. This also takes some time to implement.
     
     
   • If you chose to serve a single graphic and have the browser scale it, the results will probably be less than perfect, and could even be ugly depending on the amount of scaling.
     
     
   • A large number of media queries could unnecessarily bloat the CSS and negatively impact on page loading speeds.
     
     
   • Will look great on older browsers and devices, but not so great on newer ones.
     
2. SVGs with single PNG/JPEG/GIF fallback
   
   • You could use SVGs everywhere and then have it fallback to another format for browsers that don't support SVG. The main advantage is you only need one file for all the different resolutions.
     
     
   • If you compromise and accept that users on outdated browsers can live with imperfectly scaled graphics, you would only need one other version of each file in PNG, JPEG or GIF format.
     
     
   • This would take a similar amount of time to implement as the PNG only media queries - possibly even less, meaning it would probably be around the same price.
     
     
   • Will look great on all new devices, with sacrifices being made on older technology.
     
3. SVG with multiple PNG/JPEG/GIF fallbacks dependant on resolution and screen size
   
   • You could serve SVG first, and then resolution-dependant PNGs for browsers that don't support SVG. This would be the most thorough, most backwards and forwards compatible, most consistent and most expensive time-consuming option.
     
     
   • It would probably take as much time as 1 & 2 combined, plus a little extra for working out the kinks.
     
     
   • Will look amazing on almost every device.
     

In summary, I think it depends on whether you're looking for more backward compatibility or more forward compatibility, and how much money time you have to spend.

 

[RichardKYA]

Thank you Daniel

That makes sense. I think I will just go with planning for the future, the browsers I've tested on seem to handle svg sprites fine and I would assume that most people that use a mobile device for internet purposes will have a device that can handle it as well.

I guess time will tell though lol

Thanks again

 

[eva2000]

don't forget webp Lossless and Alpha Gallery

 

[Arty]

Rendering time. SVG images render much slower than PNG images. Performance difference is huge.

If you have multiple SVG images on same page, it becomes much slower. If you know dimensions of your images, its easier to convert SVG to PNG and add additional 2x PNG image for high definition displays (its easy to target hd devices with media queries).

Then there is an issue of SVG images being limited to raw shapes. You can't create shiny gradients, shiny shadows or anything like that. With PNG images you can do anything your image editor allows you to do.

 

[RichardKYA]

Maybe I should just create both, then it covers all bases and I can test the performance.

Thank you for your input guys

 

[rdn]

You can't create shiny gradients, shiny shadows or anything like that.

I have an SVG logo like that:
https://www.phcorner.net/styles/default/phcorner/logo/logo.svg

 

[RichardKYA]

its easy to target hd devices with media queries

In your opinion, what would be the best queries to use? I've had a search and there are a lot of different ones regarding hd devices, so I'm not sure which ones would be relevant for today?

Thank you

 

[digitalpoint]

Also the type of image comes into play. SVG does well with things like logos (drawn things). Doesn't really work for things like photographs.

 

[W1zzard]

SVG images being limited to raw shapes. You can't create shiny gradients, shiny shadows or anything like that.

Actually these can be created just fine

http://www.nextpowerup.com/images/logo.svg

 

[Jake Bunce]

I recently implemented the SVG format for flowchart exports from Visio. One neat thing about SVG is that you can manipulate and bind to it with javascript because it is XML. So I was able to, for example, bind click actions to various nodes in the flowchart.