To compress images for the web, resize them to the largest display size you actually need, choose the right format, then lower quality until visible artifacts appear and step back up.
If you already have images ready to test, open the Image Compressor, add JPG, PNG, or WebP files, set a max width and quality value, then compare the before and after sizes.
Resize before compression
Dimensions usually matter more than the quality slider. A 4000px wide photo displayed at 1200px sends extra pixels the browser will never show at full size.
Start with the largest rendered size in the layout:
| Image role | Starting max width |
|---|---|
| Full-width hero | 1600-1920px |
| Article image | 1000-1400px |
| Product card | 600-1000px |
| Thumbnail | 300-600px |
These are starting values, not universal targets. Retina displays and responsive layouts may need larger source images, but the source should still be tied to a real display size.
Pick the format by image type
Compression works differently by format.
Use WebP for most web photos and mixed graphics when your publishing system supports it. It often reaches smaller file sizes than JPEG at similar visual quality and can also store transparency.
Use JPEG for photos when broad compatibility and predictable CMS handling matter. JPEG does not support transparency and repeated re-saving can add artifacts.
Use PNG for sharp UI screenshots, logos, diagrams, and images that require exact transparency. PNG is lossless in typical browser exports, so a quality slider will not reduce it the way it reduces JPEG or WebP.
Set quality by looking, not guessing
A good starting point for photos is 75-85 quality for JPEG or WebP. Lower the value until you can see banding, blockiness, smeared texture, or noisy edges, then move back up.
Different images react differently:
- smooth gradients show banding early
- faces reveal artifacts quickly
- noisy photos compress poorly
- screenshots may blur text at low quality
- flat illustrations can often go lower
Do not reuse one quality value across every image without checking the result. The right value depends on the source.
Batch compression in the browser
The Image Compressor handles the common web pass in one place: max width, output format, quality, preview, file-size comparison, and ZIP export for batches.
Compression runs in the browser; files are not uploaded. That matters when you are compressing client images, product shots, unpublished campaign art, or screenshots from private tools.
A normal batch pass looks like this:
- Add the original images.
- Set a max width, such as
1600for article and hero images. - Choose
WebPorJPEGfor photos. - Start around
80quality. - Compare previews and file sizes.
- Download individual files or the batch ZIP.
Responsive images still matter
Compression reduces each file. Responsive image markup helps the browser choose the right file for each viewport.
For production pages, pair compressed assets with srcset, sizes, or a <picture> element when your stack supports it. That lets a phone load a smaller version than a desktop monitor.
A compressed 1800px image is still wasteful if the browser only needs 640px on mobile.
Metadata and repeated exports
Canvas-based compression often removes EXIF metadata, including camera details and sometimes orientation information. That can reduce file size, but it also means you should check whether the image rotates correctly after export.
Avoid compressing an already compressed file over and over. Keep the original, export a web copy, and make the next version from the original when possible. Repeated lossy exports compound artifacts.
Check the page after upload
After uploading the compressed files, inspect the real page:
- Does the hero image affect Largest Contentful Paint?
- Are width and height set so layout does not shift?
- Does the crop still work on mobile?
- Do gradients, faces, text, and product edges still look acceptable?
- Is the image cached with sensible headers?
The final test is not the converter preview. It is the page where the image will load.
