This is a small decision that people re-make every single time, usually by picking whatever the tool defaulted to. It takes five minutes to learn and then it is free forever.
The three-line version
- Screenshots and UI — PNG. Sharp edges and flat color, which is exactly
- what PNG compresses well and JPG compresses badly.
- Photographs — JPG. Smooth gradients, no hard edges, and JPG is a
- fraction of the size.
- Anything on your own website — WebP. Smaller than both at the same
- quality, supported by every browser people actually use.
That covers about ninety percent of decisions. The rest is the interesting part.
Why a screenshot in JPG looks dirty
JPG compresses by throwing away detail in blocks of eight pixels, and it throws away the kind of detail that sits at a hard boundary between two flat colors.
A photograph has almost no hard boundaries, so you never see it. A screenshot is made of hard boundaries — the edge of a button, black text on white, a one-pixel border — and JPG puts a faint halo of noise around every one of them.
At high quality settings it is subtle. It is still there, and on text it reads as slight blurriness that you cannot point at. This is the main reason some product pages look faintly cheap for no identifiable reason.
Screenshots go out as PNG or WebP. Not JPG.
Why your PNG is four megabytes
The usual answer is that it is a 3200-pixel-wide export being displayed at 800 pixels.
Export at roughly twice the display size and no more. A hero image that appears 800 pixels wide wants to be 1600 across for high-density screens. Beyond that you are sending bytes nobody can see.
The second answer is that PNG stores an alpha channel whether you use it or not. If your background is a solid color, flattening it removes the channel and a chunk of the file.
Transparency, and where it will bite you
A transparent PNG is genuinely useful: it lets a mockup sit on any background, in a deck, on a colored section, in an email with a dark mode.
Two places it causes real problems.
App stores reject it. Both Apple and Google refuse store screenshots with an alpha channel. This is the single most common reason an otherwise correct submission fails, and the image looks completely fine to you because your viewer renders the transparency as white.
Email clients render it badly. Several will composite transparency onto black. A transparent logo becomes an invisible logo in Outlook.
The rule: transparency for anything you will place yourself, a flattened background for anything you hand to a platform.
WebP, briefly
WebP is smaller than PNG for screenshots — commonly 25 to 35 percent — and smaller than JPG for photographs, at matched quality. It supports transparency. Every browser in current use supports it.
Use it for images on your own site, where you control the pipeline.
Do not use it for anything you hand to someone else. Slack previews it inconsistently, some email clients do not, a few desktop apps still open it in a browser, and a client who cannot open your file will not investigate why — they will ask you to resend it as a PNG, and now you have done the job twice.
SVG is worth one line: it is for vectors — logos, icons, diagrams. A screenshot cannot be an SVG in any useful sense. Put an SVG logo on your site and never think about its resolution again.
Actual numbers to aim for
- Hero image — under 300KB. This is in your largest contentful paint and
- it is the number your page speed score is mostly made of.
- In-body images — under 150KB each, and lazy-loaded below the fold.
- Email — under 200KB total for all images. Several clients clip
- messages over about 100KB of HTML, and slow images on mobile data mean the
- message is read as text.
- Social uploads — do not bother compressing hard. Every platform
- re-encodes what you upload, so send it large and clean and let them ruin
- it their way rather than compounding two compressions.
That last point catches people out: exporting a heavily compressed JPG for Instagram means Instagram then compresses your already-compressed file. Send the good version.
Every platform re-encodes. Optimize for your own site, where the bytes are yours, and upload the clean file everywhere else.
The decision, one more time
- Screenshot going on your site → WebP
- Screenshot going anywhere else → PNG
- Photograph → JPG, or WebP on your own site
- Logo or icon → SVG
- App store → PNG or JPG, flattened, no alpha
Pin that somewhere and stop re-deciding.