Compressing Images for the Web: JPG vs PNG vs WebP, Quality Settings and Dimensions
Images are usually the heaviest part of a web page, and the largest image above the fold is very often the element that decides Largest Contentful Paint. A single unoptimised phone photo can weigh several megabytes; the same photo correctly sized and compressed for a blog post is usually well under 200 KB with no visible difference.
Getting there takes three decisions, in this order: the right dimensions, the right format, and the right quality setting. This guide covers each with numbers you can apply today.
Start with dimensions, not compression
Resizing is the biggest saving and the one most often skipped. A modern phone camera produces images around 4000 × 3000 pixels, 12 megapixels. If that image is displayed in an 800-pixel-wide content column, the browser downloads roughly 25 times as many pixels as it shows and then throws them away.
Size images to the largest width they will be displayed at, multiplied by 2 for high-density (retina) screens. An 800 px column needs a 1600 px image at most. A 360 px thumbnail needs 720 px. Going beyond 2x gives no visible benefit on almost any device.
For responsive layouts, generate two or three widths and let the browser choose with srcset and sizes. Always include width and height attributes so the browser reserves space and the page does not shift while the image loads.
<img
src="team-1200.webp"
srcset="team-600.webp 600w, team-1200.webp 1200w, team-1800.webp 1800w"
sizes="(max-width: 700px) 100vw, 800px"
width="1200" height="800"
alt="Support team at the Chennai office"
loading="lazy">JPG, PNG, WebP, and AVIF: which format
Each format has a job. Pick by image content, not habit.
- JPEG: photographs and complex images with gradients. Lossy, no transparency, supported everywhere. Still a safe default for photos if you cannot serve WebP.
- PNG: screenshots, diagrams, logos, and anything that needs sharp edges, text, or transparency. Lossless, so photographs saved as PNG are often five to ten times larger than the JPEG equivalent.
- WebP: supports both lossy and lossless compression plus transparency, and is supported by all current major browsers. Google's own comparisons found lossy WebP files 25 to 34% smaller than JPEG at equivalent quality. A good default for both photos and graphics on the web.
- AVIF: usually smaller again than WebP at the same quality, with transparency, and supported by current versions of Chrome, Edge, Firefox, and Safari. Encoding is slower, and some CMSs and email clients do not handle it yet.
- SVG: logos, icons, and simple illustrations made of shapes. Scales to any size at a tiny file size. Not for photos.
Quality settings that do not show
Quality sliders are not percentages of anything; each encoder maps its scale differently. As working starting points, JPEG at 75 to 85 and lossy WebP at 75 to 80 are visually indistinguishable from the original for most photos at normal viewing size. Going from quality 95 to 80 often halves the file size; going from 80 to 60 saves less and starts to show artefacts.
Some content is more sensitive than others. Images with large flat areas such as sky or studio backgrounds show banding first; images with text, sharp lines, or faces show blocky edges and halos. Check those at 100% zoom before publishing. Photos with lots of fine detail like foliage or crowds hide compression well.
Never re-compress a compressed JPEG repeatedly. Each lossy save adds artefacts. Keep originals, and always export the web version from the original.
- Hero or banner photo, 1600 to 2000 px wide: aim for 150 to 300 KB in WebP.
- In-article photo, 1200 to 1600 px wide: aim for 80 to 200 KB.
- Thumbnail, 400 to 720 px wide: aim for 20 to 60 KB.
- Screenshot with text: lossless WebP or PNG; if it is still large, try lossy WebP at high quality and check the text stays crisp.
Metadata, transparency, and other details
Photos from phones carry EXIF metadata: camera model, timestamps, and often GPS coordinates. It adds kilobytes and can leak the location where the photo was taken. Strip it for web use unless you specifically need it, while making sure orientation is applied to the pixels first so images do not appear rotated.
If a PNG has a solid background and no transparency, converting it to JPEG or lossy WebP is usually a large win. If it needs transparency, use WebP rather than PNG for photographic content. For line art and logos with few colours, an optimised PNG or SVG may remain the smallest option.
Why it matters for page speed
Image weight affects Core Web Vitals directly. The LCP element on most content and product pages is an image, and its download time is part of LCP. On a slow mobile connection, cutting a hero image from 1.5 MB to 150 KB can take more than a second off LCP on its own. Smaller images also mean lower bandwidth costs and better experience for visitors on metered data.
Two loading rules go with compression. Lazy-load images below the fold with loading="lazy", but never the main image at the top of the page; add fetchpriority="high" to that one instead. And make sure every img has width and height, which prevents layout shift (CLS) as images arrive.
A five-minute workflow
For a handful of images, this sequence covers almost every case: resize to 2x the display width with the Neemtools Image Resizer, convert photos to WebP with the JPG to WebP or PNG to WebP converter (use PNG to JPG for opaque graphics if WebP is not an option), and fine-tune quality in the Image Compressor while comparing against the original. All of these run in the browser, so images are not uploaded to a server. After publishing, run the page through Page Speed Insights to confirm the image is no longer flagged in the opportunities list.
For sites with many images, automate the same steps in your build or CMS with an image CDN or a tool such as sharp or Squoosh CLI, so editors cannot upload a 5 MB photo straight to production.