Shrink JPG, PNG and WebP file sizes, resize dimensions, and convert between formats — all in your browser. Nothing is uploaded.
This reduces image file size by re-encoding at a lower quality setting and, optionally, at smaller dimensions. Both levers matter, and most people reach for the wrong one first.
JPG and WebP compression exploit the fact that human vision is far more sensitive to brightness than to fine colour detail, and poor at noticing high-frequency variation. The encoder transforms the image into frequency components and discards those the eye is least likely to miss. Turning the quality setting down discards more of them.
This is the single most effective change, and it is the one people skip. Serving a 4,000-pixel-wide photograph into a container 800 pixels wide wastes most of the file regardless of how well it is compressed — the browser downloads every one of those pixels and then throws them away.
File size scales with the square of the dimensions. Halving both width and height cuts the pixel count to a quarter, which typically cuts the file by around 75% before any quality reduction at all.
| Use | Sensible maximum width |
|---|---|
| Full-width hero image | 1,920-2,400 px |
| Blog body image | 1,200 px |
| Product thumbnail | 400-600 px |
| Avatar or icon | 200 px |
| Email attachment | 1,600 px |
Double these for high-density displays if the image needs to stay sharp on a retina screen, and serve the larger file only to those devices using srcset.
The relationship between quality and file size is steeply non-linear, which works in your favour.
| Quality | Appearance | Relative size |
|---|---|---|
| 95-100 | Visually lossless, and wasteful | Very large |
| 85-90 | No visible loss in normal viewing | Baseline |
| 75-85 | Excellent for web — the usual choice | 60-70% |
| 60-75 | Slight softening on close inspection | 40-50% |
| Below 50 | Visible blocking and colour artefacts | 25% |
Dropping from 100 to 90 often halves the file with no perceptible change. Dropping from 80 to 70 saves much less and costs noticeably more. Around 80 is where most photographs sit best.
Artefacts do not appear evenly across an image. Watch these areas when judging a setting:
An image that is mostly flat colour with sharp edges — a screenshot, a chart, a logo — should not be a JPG at all. PNG or WebP handles that content far better and usually smaller.
Every save at a lossy setting discards information permanently, and re-compressing an already-compressed image compounds the damage across the whole picture rather than just the part you changed. Always keep your originals and compress copies. If you need a different size later, go back to the original rather than resizing the compressed version.
Images are typically the largest component of page weight, so this is usually the biggest available performance win. Largest Contentful Paint — one of Google's Core Web Vitals and a ranking signal — is normally determined by the biggest image on the page.
Alongside compressing, three things help: convert to WebP, which is 25-35% smaller than JPG at the same quality; add loading="lazy" to images below the fold; and set explicit width and height attributes so the browser reserves space and the page does not shift as images arrive.
All processing runs on your device through the Canvas API. Your images are never uploaded, which means no queue, no server-imposed size limit and no copy of your photographs on anyone else's disk. Metadata including GPS coordinates is dropped in the process, which is generally desirable before publishing a photo online.
Around 80 for photographs on the web. Dropping from 100 to 90 typically halves the file with no visible change; below about 60 artefacts become apparent in skies and around edges.
Resize first — it usually saves more. File size scales with the square of the dimensions, so halving width and height cuts the file by roughly 75% before you touch the quality slider.
No. Lossy compression discards data permanently. Always keep your originals and compress copies, and go back to the original if you need a different size later.
Because JPG compression is designed for photographs and handles sharp edges poorly, producing halos around text. Screenshots, charts and logos should be PNG or WebP, which often produces a smaller file for that content anyway.
No. Compression runs entirely in your browser using the Canvas API. Nothing is transmitted, and the tool keeps working if you disconnect after loading the page.