Background file formats and resolution: a practical guide
Last reviewed on 28 April 2026.
The format and resolution you ship a background in decide how heavy the page becomes, how sharp it looks on a high-density display, and how it survives once it has been resized for a tablet, a phone, and a printer. Most of these decisions come down to a small set of trade-offs that recur across projects.
The five formats that matter
For backgrounds you will choose between five formats most of the time: JPEG, PNG, WebP, AVIF and SVG. Each is good at something different.
| Format | Best for | Avoid for |
|---|---|---|
| JPEG | Photographic and gradient-heavy backgrounds where small artefacts are invisible. | Backgrounds with sharp edges, type, or transparency. |
| PNG | Backgrounds with hard edges, flat colour areas, or transparency (PNG-32). | Photographic gradients — file sizes balloon for no visible benefit. |
| WebP | Most web backgrounds today: lossy WebP outperforms JPEG, lossless WebP outperforms PNG. | Print pipelines that don't yet support it; very old browsers. |
| AVIF | The smallest file at the same quality. Worth the encode time for a hero image. | Build pipelines that don't have an AVIF encoder, or contexts where the marginal saving is not worth the extra format. |
| SVG | Geometric and pattern-based backgrounds — see the geometric backgrounds hub for examples — that are intrinsically vector. | Photographic content, complex gradients with thousands of colour stops, or backgrounds that can't be expressed mathematically. |
How to choose the right format for the kind of background
Solid and near-solid backgrounds
A flat solid background almost never needs a file at all — a CSS background-color declaration is the right answer. If you must export it as an image (for a slide deck or a social card), a small PNG is fine; a JPEG can introduce visible banding in large flat areas.
Gradients
For pure two- or three-stop linear gradients on the web, prefer the CSS linear-gradient() function over a raster image. CSS gradients render at any resolution, weigh nothing, and don't band on high-density displays. The same applies to radial and conic gradients. Reach for an exported file only when the gradient is too complex to express in CSS — for example, a hand-tweaked mesh gradient with many control points. In that case, WebP or AVIF gives the best size-to-quality ratio.
Abstract and textured backgrounds
Photographic-feeling abstracts and textures are where the format choice matters most. JPEG remains a sensible default for an export pipeline that doesn't have WebP/AVIF, but the gain from moving to WebP — typically 25–35% smaller at visually identical quality — is meaningful for a hero background. AVIF doubles down on that saving, at the cost of a slower encode.
Geometric patterns
Anything you can describe with shapes and repetition belongs in SVG or in CSS. A repeating SVG pattern at 4 KB will look sharper at every resolution than a 400 KB raster export ever can.
Resolution and density
Two numbers control the visible quality of a raster background: the pixel dimensions of the file, and the rendered size on the user's screen. The user's display also has a device pixel ratio (DPR), commonly 2 or 3 on phones and modern laptops.
- Hero / full-bleed web backgrounds: export at twice the largest CSS rendered width — for a hero rendered up to 1920 CSS pixels wide, ship a 3840-pixel-wide source. Most pipelines also generate a 1× and a 1.5× variant via
srcsetso phones don't pay for desktop pixels. - Section backgrounds: measure the actual maximum rendered size in your design system. A panel that never gets wider than 800 CSS pixels does not need a 4K source.
- Presentation backgrounds: 1920×1080 is the practical minimum; 3840×2160 is comfortable for a 4K projector or a screen recording that may be downsampled.
- Print backgrounds: resolution is measured in pixels per inch (PPI). 300 PPI at the final printed size is the standard target. Exporting at higher PPI than the printer can resolve only inflates the file.
File weight: how much is too much?
For a public web page, a background image above ~200 KB is worth questioning. Above ~500 KB it is almost certainly the wrong choice — either the format is wrong (use WebP/AVIF), the resolution is wrong (you exported at 4K when 2× the rendered size would do), or the visual is too photographic for what is fundamentally a backdrop and could be reproduced with CSS instead. A heavy background blocks the largest contentful paint and is one of the easiest wins in a Core Web Vitals audit.
Aspect ratios and crop behaviour
Backgrounds rarely render at the aspect ratio they were exported in. CSS background-size: cover and contain change the visible portion of the image depending on the container. If the background has a focal point (a sun-burst centre, a gradient stop, an embedded shape), make sure that focal point sits within the safe area — roughly the centre 60% of the frame — so it survives both portrait and landscape crops. Test the layout at the narrowest and widest viewports your design supports.
Common mistakes
- Shipping a 4K JPEG hero on a phone-first product, where the user will never see more than a 1080p slice of it.
- Exporting a CSS-friendly two-stop gradient as a 1.2 MB PNG.
- Choosing PNG for a photographic background and seeing the page weight triple compared to a perceptually identical WebP.
- Forgetting that SVG backgrounds with thousands of nested paths can be heavier — and slower to paint — than a small raster.
- Using a single background file for both screen and print, then wondering why the print job looks soft.
Pick the format that matches the visual logic of the background, size it for the actual rendered context, and re-encode whenever a noticeably better codec ships.