SVG or PNG for a Website Background? Here's How I Actually Decide

Every time I add a new export option to TriangleBG, someone emails me asking which format they should actually pick. It’s a reasonable question and the internet gives a slightly unreasonable answer, which is usually some version of “SVG is vector so it’s always better.” That’s not true, and I’ve shipped background images that would have been worse as SVG. So here’s the actual decision process I use, minus the textbook explanation you’ve probably already read three times.

The one-sentence version

Use SVG when the image is made of simple shapes and needs to scale across a lot of screen sizes without getting heavier. Use PNG when the image has a lot of visual complexity, needs to look identical everywhere, or you need it to just work without thinking about rendering cost. For a triangle background specifically, both are usually fine, and the deciding factor ends up being something people rarely think about upfront: how many triangles are actually in the image.

Where SVG genuinely wins

SVG is a text-based format. A triangle in SVG is just three coordinates and a fill color, written out as markup. That has a few real advantages I use constantly:

It stays sharp at any size.Stretch it across a 21-inch monitor or a phone screen, it’s the same file, no blur, no pixelation. A PNG made for a 1920px hero section will start showing soft edges if someone’s screen is wider than that.
You can restyle it after export.Since it’s markup, you can open the file, find a fill="#3b82f6", and swap it for your brand color without regenerating anything. Try doing that to a PNG.
It compresses extremely well when the shape count is low.A background built from forty large triangles might be 8-15kb as SVG. That’s smaller than a favicon.

The part nobody mentions is that SVG file size is roughly linear with shape count, not pixel dimensions. This is the opposite of how PNG behaves, and it’s the single most important thing to understand before you pick a format.

Where SVG quietly gets expensive

If you crank up the triangle count on a dense, small-cell pattern, you can end up with a few thousand polygons in one image. Each one is its own <polygon>element with its own coordinates and fill attribute. I’ve seen SVG exports of dense patterns come out larger than an equivalent PNG, because you’re paying a per-shape tax in markup rather than a per-pixel tax in compressed image data. On top of the file size, the browser has to parse and paint every single one of those shapes, and on a low-end phone that’s measurable rendering work, not just a download cost.

So the rule I actually follow: large, sparse patterns (bigger triangles, fewer of them) favor SVG. Dense, small-cell patterns favor PNG. If you’re using the triangle editorand you’re not sure which side of that line you’re on, generate both and check the file size before deciding — it takes ten seconds and removes the guessing.

Where PNG wins, and it’s not just “simplicity”

PNG is a raster format, meaning it stores actual pixel data, usually compressed losslessly. People treat this as a downside, but it has real strengths for background images specifically:

Rendering cost is flat and predictable.A million triangles or four triangles, once it’s a PNG, the browser’s job is the same: decode the image and paint pixels. No per-shape parsing cost.
It looks pixel-identical everywhere. No rendering engine quirks between browsers, no subtle antialiasing differences on shape edges. What you exported is exactly what ships.
It’s the safer default for complex or dense patterns, gradients with lots of stops, or anything with noise/texture layered on top, which don’t compress well as vector shapes anyway.

The tradeoff is the one everyone already knows: a PNG sized for a 4K hero image and then stretched across an ultrawide monitor will start to look soft. The fix is either exporting at a size larger than you think you need, or using the CSS image-set() function to serve different resolutions to different screens, which the MDN docs on image-set() cover well if you haven’t used it before.

What about JPEG?

I get asked this less often, but it comes up. Skip JPEG for generated patterns like triangle backgrounds. JPEG compression is built around smoothing photographic gradients and it introduces visible artifacting right along hard edges — exactly where triangle patterns have all their detail. You’ll see faint halos and blockiness along every triangle border. PNG’s lossless compression handles flat-color shapes with hard edges far better, which is exactly what a low-poly pattern is made of.

A decision checklist I actually use

When I’m not sure, I run through this in order:

Do I need to recolor or restyle this later without regenerating it? SVG.
Is the pattern dense, with a lot of small triangles? PNG, almost always.
Will this display at wildly different sizes (a background that spans from mobile to a 32-inch monitor)? Lean SVG if the shape count is reasonable.
Do I just need something that works with zero further thought? PNG. It’s the boring, safe default for a reason.

In practice, I’d guess about 70% of the backgrounds I generate for client work end up as PNG, not because SVG is inferior, but because most hero backgrounds use denser patterns than people expect, and the file-size math tips toward raster once you pass a certain triangle count.

There’s also a rendering-engine wrinkle worth knowing about: very large SVGs with thousands of shapes can hit inconsistent performance across browsers, since each one paints vector content a little differently. A PNG never has that problem, because by the time it reaches the browser it’s already just pixels, with no interpretation left to do. If you’re shipping a background that absolutely has to look and behave the same on every browser and device without exceptions, that predictability alone is sometimes reason enough to pick PNG even when the file size math is roughly a draw.

The part that actually matters more than the format

Whichever format you land on, compress it before it ships. A PNG straight out of most export tools carries metadata and suboptimal compression that a tool like Squoosh can usually shave 20-40% off with zero visible quality loss. For SVG, running the file through SVGOMG strips redundant precision and whitespace. I do this for every background I ship, and it’s a bigger win than agonizing over which format to pick in the first place.