When choosing a file format for a page's images, how do you decide between JPEG, PNG and SVG for a photograph, a flat UI illustration, and a logo — and what does each choice cost in bytes?
answer
- photo, flat art, or vector?
- lossy discards what eyes ignore
- lossless can't compress photo grain
- SVG cost scales with path count
basics
~20 sMatch the format to the content: JPEG for photographs, PNG when flat artwork needs exact pixels or transparency, SVG for vector art such as logos and icons that must stay crisp at any size and any screen density.
solid answer
~50 sI pick by what the image actually contains, because each format is a compression scheme built around an assumption. JPEG assumes continuous tone — it discards high-frequency detail the eye barely notices, which is very effective on photographs and poor on hard edges, and it has no transparency. PNG is lossless with full alpha, so it is cheap on flat fills and hard edges and ruinous on a photograph, where incompressible noise can make it several times the size of a JPEG. SVG is not pixels at all: it is text describing shapes, so one file serves every screen density, it compresses well with gzip or Brotli, and it stays sharp at any size — but its cost scales with path complexity, so a traced or hugely detailed drawing can be both large and slow to rasterise.
go deeper
Be ready to name the right format for a photo, a screenshot and a logo without hesitating, and to state plainly that JPEG has no transparency while PNG and SVG do.
Explain the mechanism: lossy frequency-domain compression suits continuous tone, lossless prediction suits flat colour, and vector art has no pixel dimensions so one file serves every density.
Show you decide by content class and verify the result — spotting a PNG photo in review, knowing when SVG path complexity makes a raster faster, and comparing compressed sizes rather than guessing.
Own the policy: which asset classes are permitted in which formats, where that is enforced so a wrong export cannot reach production, and what an approved exception costs the team.
## Formats encode an assumption about the content Every image format is a compression scheme built around a guess about its input. Choosing well means matching that guess to your artwork; choosing badly costs you either bytes or visible quality, usually a lot of one of them. **JPEG assumes a photograph.** It assumes colour varies smoothly, that some noise is normal, and that small errors go unnoticed. It cuts the image into 8x8 blocks, converts each into frequency coefficients with a discrete cosine transform, and quantises away the high-frequency detail the eye is least sensitive to. It usually also stores colour at half resolution — chroma subsampling — because human vision resolves brightness far better than hue. On a photo that is nearly invisible and hugely effective. JPEG cannot store transparency and cannot animate. **PNG assumes a synthetic image.** Flat fills, hard edges, a limited palette, pixels that must come back exactly as they went in. It predicts each pixel from its neighbours and DEFLATE-compresses the residual, and it supports full 8-bit alpha. On a screenshot, an exported logo, a UI illustration or a chart, lossless costs very little because long runs of identical or predictable pixels compress to almost nothing. On a photograph it is a disaster: photographic grain is incompressible if you refuse to discard anything, so a PNG of a photo is routinely five to ten times the JPEG. PNG has two shapes worth knowing. PNG-8 is palette-based — at most 256 colours, with cheap binary or indexed transparency — and is excellent for simple flat icons. PNG-24/32 is truecolour with a full alpha channel and is what design tools export by default, which is why oversized PNG photos keep appearing in repositories. **SVG is not a raster format at all.** It is XML markup describing shapes, strokes and fills. Consequences that matter for performance: - It is resolution-independent, so one file covers 1x, 2x and 3x displays with no variants. - It is text, so it compresses very well over the wire with gzip or Brotli — compare the compressed size, not the raw size, when you weigh it against a PNG. - Its cost scales with the number of path nodes, not with pixel dimensions. A 2000px-wide logo with twelve paths is tiny. An illustration auto-traced from a photograph can hold tens of thousands of nodes, and the browser has to parse and rasterise every one. ```html <svg viewBox="0 0 24 24" width="24" height="24" aria-hidden="true"> <path d="M12 2 2 22h20L12 2z" fill="currentColor"/> </svg> ``` That is the whole icon, at any size, in far fewer bytes than a 3x PNG of the same triangle — and `currentColor` lets it follow the surrounding text colour instead of shipping a second file for a dark theme. ## Where each choice goes wrong - **JPEG for a screenshot with text.** The quantisation that hides grain in a photo produces visible ringing around letterforms, and chroma subsampling smears coloured text edges. - **PNG for a hero photo.** Megabytes where a couple of hundred kilobytes would do. This is the single most common image mistake in real codebases. - **SVG for a photographic or auto-traced illustration.** Enormous markup and real main-thread rasterisation cost. - **GIF for anything still.** A 256-colour palette and weak compression; a PNG or SVG beats it on quality and size. ## Transparency is a real constraint, not a preference If the image must sit over an arbitrary background with soft edges, JPEG is out — it has no alpha. Historically that alone pushed logos and cut-out product shots to PNG even when they were photographic, which is exactly the case where modern lossy formats with alpha earn their keep. ## What modern formats change, and what they do not WebP and AVIF cover both jobs: they have lossy modes for photographs and lossless plus alpha modes for flat artwork. So the question becomes "lossy or lossless?" rather than "JPEG or PNG?", and a photograph that needs transparency is no longer forced to be lossless. What does not change is raster versus vector: nothing replaces SVG for a logo, an icon or a diagram that must be crisp at every density, and nothing makes a traced photograph a sensible SVG. ## A decision path you can say out loud 1. Is the artwork vector-authored — a logo, an icon, a simple diagram? Use SVG. 2. Is it photographic? Use a lossy raster format. 3. Is it flat art, a screenshot, or does it need exact pixels or crisp alpha edges? Use a lossless raster format. 4. Is it a tiny UI mark? Prefer SVG; below a few kilobytes, a raster file's fixed header and container overhead starts to dominate the payload.
- A designer hands you a 3 MB PNG of a product photograph with a transparent background. What do you do?The transparency is why it is a PNG, and lossy JPEG cannot replace it. I would re-encode it as a lossy format that supports alpha — WebP or AVIF — which typically brings a cut-out photo down to a small fraction of the PNG, and keep a lossless or JPEG-on-a-solid-background fallback only if the delivery path needs one.
- When is a PNG actually the better choice than an SVG for an icon?When the artwork is not really vector: a heavily detailed or auto-traced mark with thousands of nodes, an icon with raster effects or embedded photos, or anything whose compressed SVG is larger than a small PNG. Compare the gzipped SVG against the PNG rather than assuming vector always wins.
- Why should you compare a compressed SVG's size rather than its file size on disk?SVG is XML text with lots of repetition, so gzip or Brotli typically shrinks it dramatically — often to a third or less. Judging it by raw bytes makes it look far worse against a PNG than it will be over the wire, since the PNG is already compressed and gains almost nothing from transport compression.
saying these in an interview costs you the question
- PNG is higher quality, so always export PNG
- JPEG supports transparency if you save it correctly
- SVG is always smaller than a raster image
- GIF is fine for logos because it is lossless
- Format does not matter, the CDN compresses everything