Two completely different ideas of what an image is
A PNG is a grid of colored dots. Four hundred pixels wide means four hundred columns of dots, each with a stored color, and that is the entire story. An SVG is not a grid of anything. It is a text file of instructions: draw a circle here with this radius, fill it with this blue, put this curve next to it. The browser follows the instructions fresh every time, at whatever size is asked.
That single difference explains every practical behavior of both formats. Scale a PNG up and the dots get stretched and smeared, because there is no more information to reveal. Scale an SVG up and the browser simply redraws the shapes larger, perfectly crisp, because instructions do not have a resolution. MDN's SVG reference, linked below, shows what those instructions literally look like; an SVG opens in a text editor like any other code.
Scaling: the demo that sells vectors
Take a company logo as a 200 pixel PNG and put it on a conference banner at 2 meters wide. The printer needs thousands of pixels; you have 200. Every curve becomes a staircase. Now take the same logo as SVG. The banner version, the business card version, and the tiny header version are the same file, all perfectly sharp, because the shapes are recomputed at each size.
The same logic runs in reverse for file size. A simple logo as SVG might be two or three kilobytes of text, and it stays two or three kilobytes whether displayed at 16 pixels or 1600. A PNG's weight grows with its dimensions because there are literally more dots to store. Doubling both dimensions quadruples the pixel count: a 400 by 400 image holds 160,000 pixels, an 800 by 800 holds 640,000. That is the arithmetic behind why raster assets shipped at retina sizes get heavy so fast.
Where the crossover flips: photos and complexity
So why not use SVG for everything? Because instructions only stay small when the picture is simple. A photograph is millions of dots with no pattern a shape can describe. Tracing a photo into vectors produces either a huge unusable file or a posterized cartoon of the original. Photos are raster territory, permanently, and the real question for them is compression format, which I covered in WebP vs JPG vs PNG.
The crossover also bites on genuinely complex illustrations. A highly detailed vector drawing with thousands of paths and gradient meshes can outweigh a PNG of the same artwork and render slower, since the browser must compute every shape. My working rule, labeled as such: if the artwork has more than a few hundred distinct shapes or any photographic texture, raster it. If it is flat shapes, text, and clean curves, vector it.
- SVG territory: logos, icons, charts, diagrams, illustrations with flat color and clean geometry, anything that must scale.
- PNG territory: photographs, screenshots, artwork with textures or grain, images destined for platforms that reject SVG.
- Judgment calls: complex illustrations, where you test both and compare weight and rendering.
The export gotcha that has embarrassed everyone once
Here is my admission for this post. Years ago I sent a client their finished logo as an SVG exported with live text, meaning the file said render the words in the brand font rather than containing the drawn letterforms. On my machine, with the font installed, it looked perfect. On theirs, the browser substituted a default serif, and the logo they forwarded to a printer went out in something close to Times New Roman. Nobody caught it until the proofs arrived.
The fix is one checkbox with several names: convert text to outlines, or to paths, or to curves, depending on the tool. It replaces the font reference with the actual letter shapes, so the file no longer depends on any font being installed. The tradeoff is that the text stops being editable, so keep a working copy with live text and export outlined copies for anything leaving your machine.
SVGs have quieter gotchas too. Effects and filters from design tools do not always survive export, embedded raster images can hide inside an SVG and destroy its scalability, and files exported from heavy editors often carry kilobytes of metadata cruft. Open the exported file, look at it at several sizes, and treat the export step as part of the design, not an afterthought.
When you need pixels anyway: converting well
Plenty of destinations still demand raster. Social platform uploads, email clients, app store listings, marketplace forms, and most document tools want PNG or JPG. The right move is to keep the SVG as your master and rasterize per destination at the exact pixel size needed, using an SVG to PNG converter. Render at the final size, never render small and scale up afterward.
Favicons deserve a special mention because they are the extreme case: the same mark must survive at 16, 32, 180, and 512 pixels. Modern browsers accept SVG favicons, but the compatibility story still favors generating the full raster set, which is exactly the job of a favicon generator. And if the rasterized asset is a flat graphic heading to the web, converting it with an image to WebP pass usually shaves the weight further without visible cost.
The decision, condensed
Ask what the image is made of. Shapes and text: SVG, with text outlined before it travels. Dots of the world, meaning photos and textures: raster. Ask where it is going. Your own website: SVG is safe and has been for years. Someone else's upload form: check, and expect to rasterize.
Most identity assets deserve both: one vector master that never degrades, and a small folder of rasters generated from it at the sizes reality demands. The master is the asset. The PNGs are just the delivery format.
Questions people ask
For shapes, text, and flat graphics, yes: SVG stays perfectly sharp at every size because it is redrawn from instructions. For photographs, SVG is not merely worse, it is the wrong category. Quality depends on matching format to content, not on one format being superior.
Most often, live text. If the file references a font instead of containing outlined letterforms, machines without that font substitute another. Convert text to paths before sharing. Unsupported filters and effects from design tools are the other common culprit.
Modern browsers support SVG favicons, but coverage across older browsers, pinned tiles, and platform quirks is uneven. The dependable approach remains generating the standard set of PNG and ICO sizes from your vector master.
Usually an embedded raster image hiding inside it, or thousands of paths from an auto-traced photo, or editor metadata bloat. Open the file in a text editor: if you see a giant base64 block, there is a bitmap inside your vector.
On the web, SVG: they are lines, shapes, and text, exactly what vectors do best, and they stay crisp on high density screens. Export to PNG only for destinations that cannot take SVG, like most email clients and office documents.
