How to Compress Images for the Web
A practical workflow for reducing web image file sizes while controlling dimensions, format and visible quality.
Published
To compress an image for the web, first resize it to realistic display dimensions, then choose a suitable format and reduce quality until the next reduction causes visible damage. The best result is not automatically the smallest file: it is the lightest version that still performs its intended visual job.
This workflow works for individual images and for batches. It also gives you a defensible reason for each setting instead of relying on a universal quality number.
The short version
Start from the image’s largest intended display size.
Test WebP first for general web use and AVIF for large photographic assets.
Use JPEG when a traditional fallback is required and PNG when lossless detail or transparency is the priority.
Compare the result at its intended size, not only while zoomed into individual pixels.
Keep the original file outside the optimized delivery set.
The order that prevents wasted work
Measure the slot
Find the largest rendered width and the display densities you intentionally support.
Set dimensions
Resize proportionally before choosing the final compression setting.
Encode candidates
Test formats and settings suited to the photograph, graphic or transparent asset.
Inspect in context
Review normal display size first, then diagnose vulnerable detail more closely.
Publish the right width
Save the approved output and provide responsive widths where the layout needs them.
Dimensions, encoding and delivery are separate decisions. Make them in this order so you do not tune quality for pixels the layout will discard.
Compress an image step by step
Identify the display context
Find the widest slot in which the image will appear. Note whether it is a prominent hero, a product image, an article illustration or a small thumbnail. Prominent images usually justify more conservative compression than small supporting assets.
Set appropriate pixel dimensions
If the source is much wider or taller than the delivery requirement, resize it first. Dimensions and compression solve different problems: resizing removes pixels the layout cannot use, while compression encodes the remaining pixels more efficiently.
Choose a candidate format
For a photograph, begin with WebP and compare AVIF if file weight is especially important. For screenshots or graphics with hard edges, compare PNG with lossless or high-quality WebP. Avoid JPEG for transparency and inspect text carefully whenever using a lossy format.
Reduce quality in controlled steps
Begin with a moderate-to-high setting, inspect the output and move downward gradually. Stop when the next step introduces unacceptable damage. Faces, gradients, skies, shadows, text and repeated textures often reveal compression artifacts first.
Compare size and appearance
Record the output file size, but also review the image in context. A tiny saving is not worth visible damage to a key product detail, while a thumbnail may tolerate stronger compression because visitors see it at a much smaller scale.
Download and publish deliberately
Use a descriptive filename, keep intrinsic width and height available for the page markup, and retain the original separately. If the site supports responsive images, create the additional widths needed by its image component or CMS.
Do not judge compression from file size alone
Two images exported at the same quality setting can behave very differently. A clean studio photograph, a dark textured scene and a screenshot containing small text do not have the same visual tolerance. Treat a quality number as an encoder instruction, not as an objective percentage of retained quality.
Useful starting decisions by image type
Image type. First format to test. What to inspect
Photograph. WebP, then AVIF. Faces, gradients, fine texture and shadow detail
Product image. WebP. Edges, material texture, colour and important product details
Screenshot. PNG or WebP. Small text, thin rules and flat colour boundaries
Logo or transparent graphic. PNG or WebP. Transparency, sharp edges and colour accuracy
Large hero image. WebP and AVIF. Prominent detail at desktop and mobile crops
Compression is only one part of web delivery
A well-compressed 2400-pixel image can still be wasteful when displayed in a 480-pixel slot. Responsive image markup lets the browser select among multiple widths. The srcset and sizes attributes describe the available files and expected layout size, while the picture element can offer alternate formats or crops.
The browser—not a script guessing from device names—then chooses an appropriate candidate. See the MDN responsive images guide for implementation details.
Batch compression without unpleasant surprises
Choose several representative images before applying one preset to a large batch. Include the brightest and darkest photographs, an image containing a face, a graphic with text and any file with transparency. If those outputs hold up, process the batch and spot-check the largest savings and the smallest files. Outliers deserve individual settings.
Compression questions
What quality setting should I start with?
For photographic WebP or JPEG output, a setting around 75 to 85 is often a reasonable test range, not a guarantee. Inspect the actual image and move up or down according to its content and importance.
Can I compress an already compressed image again?
You can, but repeatedly decoding and re-encoding a lossy image can accumulate damage. Return to the best available source when producing a new delivery version.
Should every image meet the same file-size target?
No. Dimensions, visual complexity and page prominence vary. Use budgets as warnings, then decide whether resizing, a different format or a quality adjustment is the right response.
Does lossless compression always produce a better web image?
It preserves pixel data, but it can create a much larger file. Lossless output is valuable for assets such as screenshots and sharp graphics; photographs often benefit from carefully judged lossy compression.
Test your own image
Apply the workflow with local browser-based processing and compare the result before downloading.