Which Image Compression Method Looks Best? A Visual Comparison
No format looks best on every image. Compare lossless and lossy methods by image type, file size, transparency, and delivery needs.
Which image compression method looks best? There is no universal winner. Lossless compression preserves image data exactly; lossy compression discards some information to make files smaller. The result that looks best depends on the image, encoder, settings, target size, transparency needs, and how it will be displayed.
For photographs, lossy JPEG, WebP, or AVIF can often reduce file size without obvious damage when encoded carefully. For screenshots, text, diagrams, and sharp-edged graphics, lossless PNG or lossless WebP often keeps edges cleaner. Compare both appearance and file size on the actual images you plan to publish.
What “looks best” means in a fair comparison
A useful comparison makes its method clear. There are two common questions, and they can lead to different winners:
- At the same file size, which looks better? Keep source image and pixel dimensions fixed, then encode each candidate to the same approximate byte budget. Inspect the visible damage.
- At similar visual quality, which is smaller? Keep the source and dimensions fixed, choose an acceptable appearance using a documented review process, and compare output sizes.
Do not compare quality numbers directly across formats. A quality value such as 80 is an encoder-specific setting, not a shared scale. A fair visual review uses the same source, dimensions, display size, and viewing conditions, and includes more than one image type.
MDN describes the distinction this way: “Compression can be lossy, discarding image data to get much smaller files, or lossless, reproducing the original exactly.” MDN’s image format guide covers the formats and their tradeoffs.
Why image type changes the winner
Photographs
Photos contain gradual changes in tone and texture. Lossy compression can simplify details in a way that is hard to notice at normal display size, especially when the output is not enlarged. Inspect skies, skin, foliage, gradients, and shadow detail for banding, smearing, or block-like artifacts.
Text, diagrams, and sharp edges
Small text, thin lines, icons, and flat-color boundaries reveal compression damage quickly. Lossy artifacts can form halos or blur around edges. Chroma subsampling can also damage high-contrast colored text. For these assets, start with lossless PNG or lossless WebP, or use SVG when the original graphic is available as vector artwork.
Transparency and animation
Check whether the output needs an alpha channel or animation. JPEG does not provide alpha transparency. WebP supports lossy and lossless compression, transparency, animation, metadata, and color profiles. Its lossless algorithm restores pixel values exactly, including color values for fully transparent pixels, as specified for that algorithm in IETF RFC 9649. This exactness does not apply to lossy WebP.
Format comparison
| Format | Compression | Usually a good starting point for | Things to check |
|---|---|---|---|
| JPEG | Lossy | Photographs and broad compatibility | No transparency; inspect fine detail, gradients, and colored text. |
| PNG | Lossless | Screenshots, diagrams, line art, and precise transparency | Can be larger than lossy alternatives, especially for photos. |
| WebP | Lossy or lossless | Web photographs and graphics where browser delivery supports it | Choose the mode for the asset; check target browsers and applications. |
| AVIF | Lossy or lossless | Web delivery where target clients support it and the encoder fits the workflow | Support is less broad than WebP; provide a fallback where needed. |
| SVG | Vector representation, not a raster compression substitute | Diagrams and graphics that need to scale cleanly | Use a genuine vector source; photographs are not a good fit. |
Google reports that lossy WebP files are 25–34% smaller than comparable JPEG files at equivalent SSIM quality, and lossless WebP is 26% smaller than PNG in its published comparisons. Those are documented comparisons, not guarantees for every image or encoder. Google’s WebP documentation describes the results.
AVIF and WebP are modern web options, but the useful choice depends on delivery compatibility as well as compression. MDN and web.dev’s image performance guide discuss format choice and fallback delivery.
How to make your own visual comparison
- Choose representative originals. Include a photograph, an image with small text or fine lines, and a graphic with flat colors or transparency.
- Fix dimensions and color conditions. Use the same pixel dimensions and color profile for every candidate. Avoid resizing one output differently.
- Encode a range of candidates. Try lossy and lossless options where supported. Test several settings per encoder; quality values are not comparable across formats.
- Compare at two targets. First target roughly similar file sizes to judge fidelity per byte. Then target similar acceptable appearance to compare file size.
- Inspect at actual display size and enlarged. Look for blur, ringing, banding, blockiness, color shifts, edge damage, and transparency problems. Judge the normal use size first; magnification helps diagnose artifacts but can overstate their importance.
- Record the conditions. Note source dimensions, encoder and version, settings, output dimensions, byte size, transparency, and the review method. Label a comparison as a test only when those steps were actually performed.
- Check real delivery clients. Verify the browsers, apps, and content pipeline that must display the image. Use a fallback for formats that your audience’s clients do not support.
For web pages, the HTML <picture> element can offer modern formats with a fallback:
<picture>
<source srcset="/images/landscape.avif" type="image/avif">
<source srcset="/images/landscape.webp" type="image/webp">
<img src="/images/landscape.jpg" alt="Mountain landscape at sunset">
</picture>
Use real, corresponding files and a meaningful alt value. The browser can select a supported source and fall back to JPEG. web.dev names Squoosh, ImageOptim, and image optimization services as ways to compress images; try different compression levels because no one setting suits every image. See web.dev’s guide.
Choosing a format for your use case
- Photograph with broad compatibility needs: Start with JPEG; compare WebP and AVIF for supported web clients at a similar visual quality.
- Screenshot or diagram with crisp text: Start with PNG or lossless WebP. Inspect text and edges before accepting a lossy version.
- Transparent graphic: Use PNG or WebP, selecting lossy or lossless WebP based on appearance and size requirements.
- Animated web image: WebP supports animation; check whether target clients support the chosen delivery format.
- Scalable logo or diagram: Prefer SVG when a vector original is available.
- Unknown audience or mixed clients: Provide a well-tested fallback rather than assuming every browser or application supports the same formats.
Performance, reliability, and cost considerations
Smaller image files can reduce the bytes a page needs to transfer, but format choice alone does not determine page speed. Dimensions, image count, responsive variants, caching, network conditions, decoding, and the rest of the page all matter. In a 2023 study of its evaluated setup, Dornauer and Felderer reported 21% page-load-time improvement for WebP and 15% for AVIF compared with compressed JPEG. These figures describe that study, not a result to expect on every site. The paper also attributed 41% of transmitted web-app data to images in its introduction and observed 4% WebP in its scraped image sample; neither figure is a current global share. See the 2023 paper.
For reliability, keep the original source, generate optimized variants reproducibly, and verify outputs in the delivery clients you support. A fallback protects delivery when a modern format is not supported. For cost, compare storage and transfer using your own image set and traffic; the available evidence does not establish a universal cost saving.
Troubleshooting image comparisons
| Symptom | Likely cause | What to do |
|---|---|---|
| One format looks worse despite a similar quality number | Quality scales are encoder-specific. | Compare visible output at equal byte budgets or tune each encoder to similar judged quality. |
| Colored text looks fuzzy | Lossy compression or chroma subsampling affects high-contrast edges. | Use lossless PNG or WebP, or test settings and inspect the actual text at display size. |
| Transparent edges show a halo or wrong color | Transparency handling or color values around translucent pixels differ. | Check the alpha channel and composite over both light and dark backgrounds; try a lossless format. |
| AVIF or WebP does not display in a target app | The client may not support that format. | Use <picture> with a fallback on the web, or select a format supported by the application. |
| A file is larger than expected | Content, dimensions, encoder, and mode affect compression; lossless output may not help a photograph. | Check pixel dimensions, compare suitable lossy modes, and measure the actual output. |
| Results differ between tools | Encoders, versions, metadata handling, and default settings vary. | Record tool and settings; compare outputs from the intended production encoder. |
| A visual result seems to change color | Color profile or metadata handling differs. | Check embedded profiles and compare in a color-managed viewer and the target delivery environment. |
Or skip the browser setup
If you need a clean visual reference of a live web page while preparing or reviewing image assets, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. The API accepts the common parameter names used by other screenshot APIs, which makes switching straightforward.
ScreenshotNeo API documentation
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`ScreenshotNeo request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));
- Cookie banners, popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
- Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed. Response headers say which page verdict applied and whether it was billed.
- An MCP server lets AI agents use
take_screenshot,get_page_info, andcapture_pdf. - 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000 screenshots. All features are available on every plan.
Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.
Frequently asked questions
Is lossless always the best-looking option?
It preserves the image data exactly, but its output can be much larger. If size matters and the image tolerates lossy encoding, a lossy result may be the more useful tradeoff.
Can I compare quality settings numerically across formats?
No. Treat each encoder’s setting as local to that encoder. Compare rendered results and file sizes instead.
Should I convert every image to AVIF or WebP?
No. Choose based on image content, acceptable appearance, workflow, and target client support, and provide fallbacks where needed.
When should I use SVG?
Use SVG when the source is a vector graphic such as a logo or diagram that needs to scale. It is not a replacement for compressing a photograph.
