PNG vs JPEG vs WebP: Choosing the Right Screenshot Format for Speed and Quality

The format parameter is easy to leave on its default and forget about. Most of the time that is fine. But the three image formats a screenshot API can output — PNG, JPEG, and WebP — trade off file size, compression artifacts, and compatibility in ways that matter once screenshots feed into something downstream, like a visual diff, a report, or a page that needs to load fast.

The Three Options

curl --request POST \
  --url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
  --header 'Content-Type: application/json' \
  --header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
  --data '{
    "url": "https://example.com",
    "format": "webp",
    "width": 1440,
    "height": 900,
    "fullSize": true
  }'

format accepts png, jpeg (or jpg), and webp for image output (plus pdf for document export, which is a separate use case covered in Turning Web Pages and Dashboards into Shareable PDF Snapshots).

PNG: Lossless, and the Right Default for Diffing

PNG is lossless — every pixel is preserved exactly as rendered. That makes it the correct choice any time the image is going into a pixel comparison, because a lossy format introduces its own compression noise on top of whatever real visual difference you are trying to measure. If you are calling v3/compare, capture both before and after as PNG so the mismatch percentage reflects actual page changes, not JPEG artifacts. See Tuning the threshold Parameter in the Visual Diff API to Avoid False Positives for how much that noise floor matters once you are gating a CI check on it.

The trade-off is file size — PNG screenshots of long full-page captures can run several megabytes, which matters if you are storing thousands of them.

JPEG: Smaller Files When Pixel-Perfect Doesn't Matter

JPEG's lossy compression shrinks file size significantly, at the cost of subtle artifacting around text edges and hard color transitions. That is a fine trade for:

• Reports and decks where a human is looking at the screenshot, not diffing it pixel by pixel.
• Support tickets and internal Slack shares where load speed matters more than exact fidelity.
• Archival captures at high volume, where storage cost adds up across thousands of pages.

It is a poor choice for anything feeding a visual diff, since JPEG artifacts can shift enough pixels to nudge a borderline comparison over your threshold for the wrong reason.

WebP: The Modern Middle Ground

WebP typically produces smaller files than JPEG at a comparable visual quality, and smaller files than PNG even at lossless settings. For screenshots that get embedded on a web page — a gallery, a documentation site, a status dashboard — WebP is usually the best fit, since it keeps page weight down without the visible artifacting JPEG can introduce at aggressive compression. The one thing worth checking before standardizing on it is whether every downstream tool in your pipeline (an old CMS, a specific reporting tool) actually renders WebP — most modern tooling does, but it is worth a quick check rather than assuming.

A Simple Decision Rule

• Feeding v3/compare or any pixel diff: PNG, always.
• Embedding in a web page, docs site, or dashboard: WebP.
• Sharing in a report, deck, or chat message where file size matters more than pixel fidelity: JPEG.
• Need a document, not an image: pdf, not a format decision at all.

Picking the right format up front avoids a second round of "why does this diff look noisy" or "why is this gallery so slow to load" debugging later — and every one of these formats runs through the same Snapshot Site endpoints, so switching between them is a one-line change, not a pipeline rewrite.