How to Compress Screenshots and Images for the Web

To compress screenshots and images for the web, first resize each image to the largest size it will actually be displayed, then compare suitable encodings at that size. Screenshots, charts, text, and line art often need lossless encoding to keep edges crisp; photographs can often use lossy JPEG, WebP, or AVIF. There is no single quality setting that works for every image: inspect the output at its expected display size and choose the smallest version that remains legible.

Keep an untouched original so you can repeat the conversion. Then deliver the right dimensions and format to each browser, using responsive markup when the layout needs multiple sizes.

1. Identify the image and its requirements

The image’s content determines what compression artifacts will be visible. A photo’s subtle texture can tolerate some changes that would make small interface text, icons, or thin chart lines look blurred.

Image or requirement	What to try first	What to check
Screenshot, UI, chart, text, or line art	Lossless PNG, WebP, or AVIF	Small text, sharp edges, colored text on flat backgrounds, and thin lines
Photograph with textures and many colors	Lossy JPEG, WebP, or AVIF	Blurring, blocking, ringing around edges, and loss of fine texture
Transparent image	PNG or an alpha-capable WebP/AVIF mode	Confirm transparency survives conversion; JPEG does not support alpha
Images shown at different sizes	Create a small set of responsive size candidates	Whether the browser receives a suitable size without excessive variants

Lossy encoding discards some visual information to reduce bytes; lossless encoding preserves the image data. Lossless does not guarantee a smaller file: compare actual candidates. MDN calls out screenshots, diagrams, logos, and line art as content where lossless encoding can avoid visible loss. MDN’s image format guide explains format tradeoffs and fallback approaches.

2. Resize to the actual display size

Compression cannot make an oversized image as efficient as a correctly sized one in every case. If a content image is displayed at 800 CSS pixels wide on a standard-density screen, a 3,000-pixel source may send more data than that view needs. For high-density screens, provide a larger candidate as well. Start with the maximum real display width needed by the page and its supported layouts, then generate a modest number of sizes.

Do not create a separate file for every possible viewport. Each variant adds storage, cache entries, and markup. The browser can choose from a small set using srcset and sizes.

3. Encode and compare candidates

Save a working copy of the source image.
Resize that copy to the intended dimensions.
For screenshot-like images, export a lossless candidate and, if useful, compare WebP or AVIF candidates. For photographs, compare lossy JPEG, WebP, and AVIF; also try a lossless candidate if fidelity is important.
Inspect candidates side by side at the size visitors will see. Zoom in on small text, icons, thin lines, and flat-color edges.
Record dimensions and file sizes. Choose the smallest candidate that passes your visual check and any product or accessibility requirements.
Serve the chosen asset and review it on the actual page, then measure page impact with your site’s performance tools.

Tools such as Squoosh and ImageOptim can help optimize individual files. MDN also lists MozJPEG as an option in Squoosh for photographs. A quality slider value is only a starting point for a particular encoder and image. As web.dev puts it, “When compressing, there isn’t a universal setting suitable for all cases.” See web.dev’s image performance guidance.

WebP can be worth comparing: Google reports lossy WebP images are 25–34% smaller than comparable JPEG images at equivalent SSIM quality, and lossless WebP images are 26% smaller than PNGs in its comparisons. Those figures are format-level comparisons, not a promise about an individual screenshot; compare your own candidates. See Google’s WebP study.

4. Serve responsive sizes and format fallbacks

Use srcset and sizes when the displayed image size varies by layout. Keep a usable src fallback. Use <picture> to offer formats in order, followed by a broadly supported fallback image:

<picture>
  <source
    type="image/avif"
    srcset="/images/dashboard-640.avif 640w, /images/dashboard-1280.avif 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
  >
  <source
    type="image/webp"
    srcset="/images/dashboard-640.webp 640w, /images/dashboard-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
  >
  <img
    src="/images/dashboard-1280.png"
    srcset="/images/dashboard-640.png 640w, /images/dashboard-1280.png 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
    width="1280"
    height="800"
    alt="Dashboard showing monthly signups by channel"
  >
</picture>

Replace the example paths, dimensions, and alternative text with the image’s actual information. The width descriptors in srcset must match each file’s intrinsic pixel width. The sizes value should reflect the rendered layout. Google Search Central recommends retaining a fallback URL in src for responsive image markup; see Image SEO best practices.

If a server or image service selects a format based on the request’s Accept header, configure shared caches to account for that variation (commonly through the Vary: Accept response header). Otherwise, a cache could serve a representation selected for a different request. Check the behavior of the origin and CDN together.

5. Load images at the right time

Lazy loading can defer offscreen images and reduce initial bandwidth. It is useful for images below the initial viewport, but do not apply it automatically to the main image needed for initial rendering. For example:

<img
  src="/images/article-illustration.webp"
  width="960"
  height="600"
  loading="lazy"
  alt="A diagram of the image compression workflow"
>

Set intrinsic dimensions to help the browser reserve space. Decide whether to lazy-load based on when that particular image appears, not just because it is an image.

6. Automate large image libraries

For a few files, a local editor or encoder is often sufficient. For a large library or frequently changing assets, an image CDN can automate resizing and browser-appropriate format delivery. MDN names services such as Cloudinary, Image Engine, ImageKit, and imgix as examples.

Automation trades manual conversion work for vendor cost, integration work, caching behavior, and decisions about how many variants to produce. Estimate the number of source images, transformations, and requests you need; confirm cache behavior and delivery formats; and compare the operational cost with your current workflow. Avoid generating every size and format combination unless the site actually uses it.

7. Troubleshoot common problems

Symptom	Likely cause	Fix
Screenshot text looks soft or has colored fringes	Lossy compression is damaging high-contrast edges	Try lossless encoding or a less aggressive lossy candidate; compare at the intended display size.
WebP or AVIF is larger than PNG	The image content or encoder settings favor PNG for this file	Keep the smaller visually acceptable output. There is no guaranteed winner for every image.
Transparent areas turn solid or black	The selected output mode discarded alpha, or the converter composited transparency	Choose an alpha-capable format and verify the exported file over both light and dark backgrounds.
Browser downloads an unexpectedly large image	The page references only a large source or the responsive size hints do not match the layout	Check the rendered width, `srcset` descriptors, and `sizes`; inspect the selected request in browser developer tools.
Modern format does not display for some visitors	No compatible fallback is available or the delivery negotiation is misconfigured	Use a `<picture>` fallback or verify server format negotiation and cache variation.
Responsive image appears stretched or layout shifts	Intrinsic dimensions or CSS sizing are missing or incorrect	Set accurate `width` and `height`, and check the CSS aspect ratio and container width.
Lazy-loaded image is missing in a screenshot or initial view	The image has not been loaded before capture, or it is needed immediately	Do not lazy-load above-the-fold imagery; for automated capture, wait for the relevant image or selector to load.
Cached image uses the wrong format	A shared cache reused a response without accounting for `Accept`	Ensure format-negotiated responses vary by the relevant request header and purge stale cache entries.

8. Performance, reliability, and cost

Measure the delivered page. Smaller image files can reduce transfer bytes, but the impact depends on which images load, the visitor’s connection, caching, and the rest of the page. Do not claim a speed or Core Web Vitals improvement without measuring the target page.
Keep an original. Re-encoding an already lossy file can compound quality loss. Generate variants from the best available source and retain it for future changes.
Use a restrained variant set. More candidates can improve size matching but add storage, cache entries, and implementation complexity. Track which variants the site actually serves.
Check cache behavior. Long-lived caching works well for versioned or fingerprinted files. When replacing files at a stable URL, make sure cache invalidation or revalidation matches the publishing workflow.
Budget for automation. Local compression tools may have no per-request service cost; a CDN can reduce manual work but has service and integration costs. Review current provider terms and usage before adopting one.

9. Capture a screenshot that is ready to optimize

If you need a screenshot as the source asset, capture the intended viewport and page state first. Check that content has loaded and that the screenshot dimensions match the largest display size you need. Then follow the resizing and comparison workflow above; capture settings do not replace image optimization.

ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. Its screenshot options include full-page capture with lazy images loaded, element capture, viewport and device presets, retina scale, and output as PNG, JPEG, or WebP. See the ScreenshotNeo API documentation for request options.

Or skip the browser setup

Request a screenshot with one GET call. This cURL example saves a WebP response:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

These examples use the request shape documented for ScreenshotNeo; consult the API docs for output and other capture parameters. The service accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents screenshot, page-info, and PDF capture tools. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000.

FAQ

Should I use PNG or WebP for a screenshot?

Compare both at the dimensions you will serve. PNG and lossless WebP are sensible candidates when text and edges must stay exact; one may be smaller than the other for a particular image.

Does converting an image to WebP always reduce its size?

No. The result depends on the source, encoder, and settings. Compare file size and visual quality for the specific image.

Is a quality setting of 75 a good default?

It can be a starting point for some photograph encoders, but it is not a universal setting. Judge the output itself, especially for screenshots and text.

How many responsive image sizes should I create?

Create a small set that covers the real layout widths and density needs. Use observed page layouts and browser requests to refine it rather than making a file for every viewport.

Can I lazy-load the first image on a page?

Only if delaying it makes sense for that page. An image needed in the initial viewport should generally be available without waiting for a lazy-load trigger.