Most images on the web are several times larger than they need to be, and the fix is rarely a cleverer compressor. It is a handful of unglamorous steps in the right order, and the first one matters more than any quality slider. Do them and a 6 MB phone photo becomes an 80 KB web image nobody can tell from the original.
The quick answer
Four steps, in this order:
- Resize to the size you actually display. This does more than any quality setting.
- Match the format to the content. WebP or JPG for photographs, PNG or lossless WebP for graphics and screenshots.
- Compress once, from the original, starting around quality 80 for photographs.
- Judge at 100 percent zoom against the original, gradients first, then edges.
The rest of this article explains why those steps hold.
What “without losing quality” honestly means
There are two kinds of compression.
Lossless compression rebuilds the original file bit for bit. PNG, lossless WebP and ZIP work this way. Nothing is thrown away, so nothing can look worse. The trade is that photographs are full of noise and subtle gradients, which lossless algorithms cannot describe compactly, so a lossless photo is usually several times bigger than a lossy one.
Lossy compression discards detail on purpose, choosing the detail your eyes are worst at noticing. JPG, lossy WebP, AVIF and HEIC work this way. The file gets dramatically smaller and the image is permanently different from the original.
So strictly speaking, you cannot compress a photo hard without losing quality. What you can reach is visually lossless: a file whose differences exist in the data but are invisible at the size the image is actually viewed. That is the honest goal, and for photographs it is achievable at roughly a tenth of the original size.
How quality sliders actually work
A JPG or WebP encoder does not store your pixels. It converts blocks of the image into frequency components, divides those by numbers from a quantisation table, and rounds the result. Coarser rounding means fewer distinct values to store, so a smaller file, and detail that can never come back.
The quality slider simply scales that table. Three consequences follow.
Quality 80 does not mean 80 percent of the quality. It is a position on a scale, not a percentage of anything, and the relationship to the visible result is strongly non-linear. Going from 95 to 85 usually saves a lot of file size and costs almost no visible quality. Going from 60 to 50 saves little and wrecks the image.
The numbers are not comparable across formats. WebP at 80 and JPG at 80 are different encoders doing different maths. A lossy WebP generally lands below a JPG of similar appearance, but never assume the same slider position gives the same look.
They are not always comparable across tools either. Two apps can both report quality 85 and produce different files. Treat any recommended number as a starting point and check with your eyes.
The single biggest win: resize before you compress
If you change one thing, change this. File size roughly tracks pixel count, and pixel count scales with the square of the dimensions, so halving the width removes about three quarters of the data before the compressor does anything.
A worked example. A phone camera typically produces 4032 by 3024 pixels, which is 12,192,768 pixels, about 12 megapixels. Say that photo appears in a blog post at 1600 pixels wide. Resized to 1600 by 1200 it holds 1,920,000 pixels. It is 4032 / 1600 = 2.52 times narrower, and 2.52 squared is about 6.35, so you have removed roughly 84 percent of the pixels. No quality setting competes with that, and unlike lowering quality it adds no artefacts, because nothing is being approximated.
This is why so many pages are slow. A 4000 pixel wide image in a 700 CSS pixel column carries about eight times more pixels than even a 2x screen can use, and over thirty times more than a 1x screen.
Work out the real display size first. A full-width hero needs 1920 to 2560 pixels to cover high-density screens, an in-content image 1200 to 1600, a thumbnail about 400. Set it with the image resizer, then compress.
Strip the metadata
Camera files carry EXIF blocks: model, lens, exposure, timestamps, GPS coordinates, sometimes an embedded preview. On a large photo that is a rounding error. On a 30 KB thumbnail it can be a meaningful share of the file.
Tinyvert re-encodes the pixels and does not carry EXIF across, so metadata is stripped automatically. For anything you publish that is usually what you want, since you are not broadcasting where a photo was taken. If you rely on capture dates or GPS tags, keep the originals.
Match the format to the content
Compression algorithms are tuned around assumptions about the image. Break the assumption and you pay for it.
Photographs have soft gradients and noise, which is exactly what lossy compression is designed for. JPG or WebP will be far smaller than any lossless option. Use JPG to WebP when the destination is a website.
Flat graphics such as logos, icons and charts have large areas of identical colour and hard edges, which lossy encoders smear. Lossless PNG or lossless WebP is smaller and cleaner here, and PNG to WebP usually wins on size, with the quality slider at 100 for WebP’s lossless mode so every pixel stays exact.
Screenshots with text are the worst case for lossy compression. Small type is high-frequency detail, exactly what quantisation discards first. Keep them lossless, and if one is still too big, crop or resize rather than lowering quality.
For the longer comparison, see WebP vs PNG vs JPG and the best image format for a website in 2026.
Why text and red edges suffer: chroma subsampling
Most JPG encoders split an image into brightness (luma) and colour (chroma), then store the colour channels at half resolution in each direction. This is 4:2:0 subsampling. It works because human vision resolves brightness detail far better than colour, and it removes a large chunk of data essentially for free.
It stops being free when the detail you care about lives in colour, not brightness. Red text on a dark background, a thin red line on grey, or a saturated logo edge can end up smeary or fringed even at a high quality setting, because the colour around that edge was stored at half resolution. That is why red often looks worse than any other colour in a compressed JPG.
For graphics and text, skip lossy JPG and use PNG or lossless WebP. For photographs, subsampling is almost never a problem.
Be honest about PNG
A lossless PNG optimiser cannot do much on its own. The format already applies a filtering and deflate pass, so re-running it saves a modest amount at best. Three things move the needle: fewer pixels, fewer colours, or a different format. Palette reduction to 256 colours shrinks flat graphics hard, though it alters the image and is not what a straight re-encode does. Resize it, convert it to WebP, or, if it is a photograph saved as PNG by mistake, convert it to JPG and watch it shrink by an order of magnitude.
Generational loss and why you keep masters
Open a JPG, save it, open it again, save it again. Each save re-quantises data that was already approximated, and because every app resizes, crops or picks its own quality, the errors compound rather than settling. That is generational loss, and it is why a much-shared meme looks photocopied.
The defence is one rule: always compress from the original. Keep a master somewhere you will not overwrite, treat every compressed file as disposable, and go back to the master when you need a different size. If your masters are iPhone HEIC files, they are already an efficient archive format, as covered in HEIC vs JPG.
A settings cheat sheet
Starting points, not laws. Check before you ship.
| Use case | Longest edge | Format | Quality | Rough size target |
|---|---|---|---|---|
| Web hero image | 1920 to 2560 px | WebP | 75 to 82 | under about 200 KB |
| Blog or in-content image | 1200 to 1600 px | WebP | 75 to 80 | under about 100 KB |
| Email attachment | 1600 px | JPG | 75 to 85 | under about 500 KB each |
| Social media post | 1080 to 2048 px | JPG or WebP | 80 to 85 | platform re-encodes anyway |
| Print, A4 at 300 dpi | around 3500 px | JPG | 92 to 95 | size is not the concern |
| Thumbnail | 300 to 500 px | WebP | 70 to 75 | under about 30 KB |
| Screenshot with text | native size | PNG, or WebP at quality 100 | lossless | resize is the only lever |
| Archive master | original | PNG, or original camera file | lossless | keep it untouched |
Social platforms re-encode whatever you upload, so a heavily compressed file takes two lossy passes. Upload good quality at the right dimensions and let the platform compress once.
How to check your result honestly
Shrinking the browser window until an image looks fine proves nothing. Judge it properly.
- View at 100 percent zoom, one image pixel to one screen pixel. Anything smaller hides artefacts.
- Look at flat gradients first. Skies, studio backdrops, shadows and out-of-focus areas are where blocking and banding appear earliest.
- Then look at sharp edges. Text, branches against sky, saturated red or blue boundaries. Halos and fringing show up here.
- Flip between original and compressed in the same position rather than viewing them side by side. Your eye catches changes far better than differences.
- Check it where it will live. An image for a phone screen may be softer than one printed at A4.
If you cannot tell them apart at 100 percent, you have not lost quality in any sense that matters. If you can, go up five or ten points and try again. The file will grow less than you expect.
The workflow, step by step
- Start from the original, not last week’s export.
- Crop first, if you are cropping. No point compressing pixels you will discard.
- Resize to the real display size with the image resizer. This does most of the work.
- Pick the format: for photographs going on a website, convert with JPG to WebP; for graphics and screenshots use PNG to WebP at quality 100, or keep PNG. The compressor keeps whatever format you feed it.
- Compress with the image compressor, starting around quality 80 for photographs.
- Check at 100 percent zoom against the original, gradients first, then edges.
- Adjust once. Too soft, go up. Comfortably under target, try going down.
- Keep the master. Archive the original, ship the output.
Sending a set of images as one document is tidier with image to PDF than as a folder of attachments.
All of this runs inside your browser on Tinyvert. HEIC files are decoded by a WebAssembly build of libheif and everything is encoded with the browser’s own Canvas API, so your images are never uploaded, never queued on a server, and never stored anywhere that could be breached. The free tier handles 5 files per batch as often as you like, and Pro removes the batch limit for a one-time US$9.
Run those four steps in order and you will ship files several times smaller that nobody notices you compressed.