To compress images for the web without an obvious loss of quality, reduce unnecessary pixel dimensions first, choose a format that matches the image, and then lower the export quality while comparing the result at its actual display size. For most photographs, WebP or a well-optimized JPEG is a practical choice. For screenshots with sharp text or images that need transparency, use PNG or lossless WebP.
The important word is obvious. Lossy compression removes data, so it cannot be mathematically lossless. However, a carefully compressed image can look the same to a visitor while downloading much faster.
A Practical Five-Step Workflow
Use this sequence for each image:
- Find the largest size at which the image will actually appear.
- Resize the source close to that display size.
- Choose JPEG, PNG, or WebP based on the content.
- Lower quality gradually and compare the result with the source.
- Deliver responsive variants so small screens do not download the desktop file.
Compression works best when these decisions are made together. Exporting a 6000-pixel photo at a slightly lower quality is still wasteful if the page never displays it wider than 1200 pixels.
Step 1: Resize Before You Compress
Pixel dimensions and compression quality solve different problems:
- Resizing removes pixels that the layout does not need.
- Compression stores the remaining pixels more efficiently.
Suppose a blog image is displayed at a maximum CSS width of 900 pixels. A 5400-pixel camera export contains six times as many pixels across, even though most visitors will never see that detail.
For a sharp result on high-density screens, exporting a version around twice the rendered CSS width is a reasonable upper bound:
Maximum rendered width: 900 CSS pixels
High-density source: up to 1800 physical pixels
This is a starting point, not a rule for every image. A detailed photograph may benefit from the larger variant, while a simple illustration may not.
Do not enlarge a small source just to reach a target number. Upscaling creates more pixels but does not restore missing detail.
Step 2: Choose the Right Image Format
No single format is best for every image.
| Image type | Good first choice | Why |
|---|---|---|
| Photograph | WebP or JPEG | Efficient lossy compression for continuous tones |
| Product photo with transparency | WebP | Supports transparency with lossy or lossless encoding |
| Screenshot with small text | PNG or lossless WebP | Preserves crisp edges and text |
| Logo or simple icon | SVG | Scales cleanly without raster pixels |
| Graphic with transparency | PNG or WebP | Preserves the alpha channel |
| Broad compatibility fallback | JPEG or PNG | Long-standing browser support |
When to Use JPEG
JPEG remains useful for photographs and broad compatibility. It does not support transparency, and strong compression can create block patterns, halos, and smearing around detailed edges.
When to Use PNG
PNG uses lossless compression and supports transparency. It is a strong choice for screenshots, interface captures, diagrams, and graphics with limited colors. It is often unnecessarily large for photographs.
When to Use WebP
WebP supports photographs, transparency, and both lossy and lossless compression. It is usually a convenient web-first format when the publishing platform accepts it.
Newer formats such as AVIF can compress some images even further, but encoding speed, tooling, and visual results vary. Test the actual output instead of choosing a format only because it is newer.
Step 3: Find a Visually Lossless Quality Level
There is no universal quality number. A setting of 80 in one encoder is not necessarily equivalent to 80 in another.
For a photograph, a quality range around 75 to 85 is a useful place to begin. Then inspect:
- Hair, grass, leaves, and fabric texture
- Text and high-contrast edges
- Smooth gradients such as skies
- Skin tones
- Shadows and dark areas
- Transparent edges around product cutouts
Use this process:
- Export at the starting quality.
- View the result at 100% and at the size used on the page.
- Reduce quality in small steps.
- Stop when artifacts become noticeable.
- Return to the previous acceptable setting.
Visitors usually see the image inside a layout, not enlarged in an image editor. The in-page comparison matters most, but a 100% check helps catch damaged details before publishing.
Step 4: Compress Images in the Browser
For a no-install workflow, use a browser-based batch compressor. The vekbox Image Tools overview explains the available compression, conversion, resizing, cropping, and batch export features.
A practical workflow is:
- Open vekbox Image Tools.
- Add the JPG, PNG, or WebP files you want to optimize.
- Select the output format and a starting quality.
- Compare the preview and output size.
- Adjust the quality if fine details look damaged.
- Export the optimized files.
Because the processing runs in the browser, the workflow is useful for quick batches and assets you do not want to upload to a remote editing service.
If a group of images also needs consistent dimensions, resize them before the final compression pass. See how to batch resize images to the same size without stretching.
Step 5: Serve Responsive Images
Compressing one desktop image is not enough if every phone still downloads it. Use srcset and sizes to provide multiple widths:
<img
src="/images/desk-1200.webp"
srcset="
/images/desk-480.webp 480w,
/images/desk-800.webp 800w,
/images/desk-1200.webp 1200w
"
sizes="(max-width: 768px) 100vw, 800px"
width="1200"
height="800"
alt="Wooden desk with a laptop, notebook, and desk lamp"
>
The browser uses the viewport and device pixel density to select a suitable file.
To provide a modern format with a fallback, use <picture>:
<picture>
<source
type="image/webp"
srcset="/images/product-640.webp 640w, /images/product-1280.webp 1280w"
>
<img
src="/images/product-1280.jpg"
srcset="/images/product-640.jpg 640w, /images/product-1280.jpg 1280w"
sizes="(max-width: 700px) 100vw, 700px"
width="1280"
height="960"
alt="Black travel backpack shown from the front"
>
</picture>
Always keep a real src on the fallback <img>. It supports browsers, tools, and crawlers that do not select a <source> candidate.
Prevent Layout Shift
Specify width and height attributes:
<img
src="/images/article-cover.webp"
width="1200"
height="675"
alt="Dashboard showing an image optimization report"
>
These attributes tell the browser the intrinsic aspect ratio before the file finishes loading. The browser can reserve space, reducing layout movement.
CSS can still make the image responsive:
img {
max-width: 100%;
height: auto;
}
Use Lazy Loading Selectively
Images below the initial viewport can use:
<img
src="/images/gallery-item.webp"
loading="lazy"
decoding="async"
width="800"
height="600"
alt="Example gallery card after image compression"
>
Do not lazy-load the primary hero or likely Largest Contentful Paint image. Delaying the most important visible image can make the page feel slower. Load that image normally and consider fetchpriority="high" only when it is genuinely the page's high-priority visual.
Image Compression for SEO
Compression alone does not make an image rank. It supports a faster, more usable page, while image discovery also depends on the surrounding page.
Use:
- A short, descriptive filename such as
blue-running-shoe.webp - Useful alt text that describes the image in context
- Relevant nearby text or a caption
- A standard
<img>element rather than a CSS background for important content - A stable, crawlable image URL
- A representative
og:imageand structured-data image where relevant
Avoid keyword stuffing:
<!-- Poor -->
<img src="shoe.webp" alt="shoe shoes best shoes running shoe cheap shoes">
<!-- Better -->
<img src="blue-running-shoe.webp" alt="Blue road-running shoe viewed from the side">
Alt text is primarily an accessibility feature. Write it for someone who cannot see the image, using the vocabulary that naturally fits the page.
How to Measure the Result
Record three values before and after optimization:
- File size in bytes or kilobytes
- Pixel dimensions
- Visual acceptability at the rendered size
Then test the real page:
- Open the browser's Network panel and reload with the cache disabled.
- Confirm the downloaded image width matches the viewport.
- Run Lighthouse or PageSpeed Insights.
- Check for an oversized-image warning.
- Inspect the page on a high-density phone and a desktop display.
A smaller file is not a win if text becomes unreadable, transparent edges develop halos, or a product's color changes noticeably.
Common Compression Mistakes
Compressing Before Resizing
The encoder spends bytes preserving pixels that will later be discarded. Resize first, then perform the final export.
Converting Every Image to JPEG
JPEG can damage screenshots, text, and transparent graphics. Match the format to the content.
Saving a Lossy File Repeatedly
Repeated JPEG or lossy WebP exports can accumulate artifacts. Keep an original master and create delivery files from that source.
Using One Huge File for Every Screen
Add responsive widths instead of asking a phone to download the desktop image.
Chasing the Smallest Possible Number
Compression has diminishing returns. Removing another 10 KB is not worthwhile if it introduces visible banding or unreadable detail.
Removing Important Rights Metadata
Metadata can increase file size, but creator, copyright, or licensing information may be legally or operationally important. Preserve required rights information even when removing nonessential camera metadata.
Frequently Asked Questions
Can an image be compressed with zero quality loss?
Yes, with lossless compression, but the size reduction may be smaller. Lossy compression can achieve a much smaller file while remaining visually indistinguishable at normal viewing size.
Is WebP always smaller than JPEG or PNG?
Often, but not always for every encoder and image. Compare actual exports. A simple indexed PNG can be smaller than a poorly configured alternative, while some photographs benefit substantially from WebP.
What quality setting should I use for WebP?
Start around 75 to 85 for photographs and adjust after visual comparison. Screenshots and text-heavy graphics may need lossless mode or a different format.
Should I compress images before uploading to a CMS?
Usually, yes, unless the CMS reliably generates correctly sized, well-compressed responsive variants. Pre-optimizing prevents oversized originals from being used accidentally.
Does a smaller image automatically improve Core Web Vitals?
It can reduce transfer time, but dimensions, responsive selection, caching, loading priority, and server delivery also matter. The page must use the optimized file correctly.
Final Checklist
Before publishing an image:
- Resize it for the largest real display size.
- Choose a format appropriate for the content.
- Compare quality at 100% and in the page layout.
- Keep an original master file.
- Generate responsive widths when needed.
- Set
width,height, and useful alt text. - Lazy-load only below-the-fold images.
- Confirm the browser downloads the expected candidate.
Official references: