Images are the largest single component of most web pages — often 60% or more of a page's total weight. Shaving a few hundred kilobytes per image is the fastest, most reliable performance win available, and it compounds: faster pages rank better, convert better, and cost less to serve.
Lossy vs lossless: the mental model
Lossless compression (PNG, lossless WebP) preserves every pixel exactly — nothing is discarded, so quality never degrades, but the savings are limited. Lossy compression (JPEG, most WebP/AVIF) discards information the human eye barely notices, achieving far smaller files. The art is pushing lossy compression until the eye catches up, then backing off one notch.
- Photos — lossy WebP or AVIF at q75–85 is visually indistinguishable from the original.
- Screenshots and UI — keep text crisp; lossless WebP or PNG.
- Logos and graphics — SVG if vector; otherwise PNG or lossless WebP.
- Icons — a single sprite or SVG, never a full-size raster.
Quality sliders are the tool
A good compressor shows you the file size change live as you drag the quality slider. Compare the preview side by side with the original — if you can't tell the difference, the quality setting is still too high.
Beyond the slider: the free wins
- Strip metadata — EXIF data (camera, GPS, software) is pure waste for the web.
- Resize to actual display dimensions — a 4000px photo shown at 800px wastes 20x the bytes.
- Choose the right format first — converting PNG to WebP is often a bigger win than any compression setting.
- Serve responsive sizes — let the browser pick 1x/2x based on the device.
ForgePlug's Image Compressor does all of this locally: upload an image, drag the quality slider, watch the size drop in real time, and download a web-ready file. The Image Converter handles the format half — converting between PNG, JPEG, WEBP, and AVIF with smart format recommendations and a live size preview. Nothing ever leaves your browser.
Compress your images now
Drag in a photo and see exactly how much you can save with a live quality slider — batch support, zero uploads, fully client-side.
Open Image CompressorWhat lossy compression actually throws away
Understanding the mechanism makes the settings far less mysterious. JPEG and its successors exploit two facts about human vision. First, we are much more sensitive to changes in brightness than in colour — so the image is split into a brightness channel and two colour channels, and the colour channels are usually stored at half resolution. This is chroma subsampling, and it is nearly invisible on photographs.
Second, we barely notice fine high-frequency detail. The image is divided into small blocks, each converted into a set of frequency components, and the high-frequency components are stored coarsely or dropped. The quality slider is essentially controlling how aggressively those components are rounded off. This is why compression artifacts look the way they do: blockiness at low settings, and a faint halo around sharp edges.
It also explains a specific failure people find baffling. Chroma subsampling averages colour across neighbouring pixels, which is harmless on a photo and destructive on saturated coloured text — red text on a blue background is the classic case, where the letters develop coloured fringes and look smeared. If an image contains coloured text or fine coloured line work, either use a lossless format or a quality setting high enough that the encoder keeps colour at full resolution.
Where the useful part of the slider actually is
The relationship between quality setting and file size is not linear, and the top of the range is where you pay the most for the least. Moving from quality 100 to 90 typically removes a large share of the file size with essentially no perceptible change, because the highest setting is spending a lot of bytes preserving detail nobody can see. From 90 down to 80 continues to save meaningfully with, on most photographs, still no visible difference. Below roughly 70 is where artifacts usually start becoming noticeable on close inspection.
The practical method is to work down rather than up. Start high, reduce until you can see a difference at 100% zoom, then step back one notch. Judge it at the size the image will actually be displayed — a flaw that is obvious when you pixel-peep at 400% may be entirely invisible in the 600-pixel-wide slot on the page.
Compression is not reversible
Re-saving a lossy image runs the process again on already-degraded data, and each round loses a little more — quality 90 applied three times is meaningfully worse than quality 90 applied once. Keep your originals and always compress from them, never from a previously compressed copy.
Why resizing beats compressing
File size scales with pixel count, and pixel count scales with the square of the dimensions. Halving an image's width and height removes three quarters of its pixels before any compression is applied. That is why serving a 4000-pixel-wide photo into an 800-pixel slot is the most expensive mistake on this list: no quality setting can recover the bytes that resizing would have eliminated outright, and pushing compression hard to compensate degrades an image that was only oversized in the first place.
Do it in the right order — resize to the display dimensions first, then compress the smaller image. Reversing the two means compressing far more pixels than you need, then throwing most of them away.
The Core Web Vitals payoff
Smaller images directly improve Largest Contentful Paint — the loading metric Google weights heavily in search rankings. Compressing an oversized hero image can move LCP from the red zone into green with zero code changes.
One extra detail that costs nothing: saving photographic JPEGs in progressive mode makes the image render as a low-detail version first and sharpen as it loads, rather than filling in top to bottom. The file size is usually similar or slightly smaller, and the page feels faster because something recognisable appears sooner.