"Compress JPG without losing quality" is a slightly tricky promise — JPG is, by definition, a lossy format. What people usually mean is: compress without visible quality loss. There are five different techniques that achieve this, each with different trade-offs. We tested each on the same set of 12 photos and measured both file-size reduction and perceptual quality (SSIM). Here’s what actually works.
Lossless vs visually lossless
Quick definitions before the methods, because the marketing language is loose:
- Truly lossless compression preserves every byte. The decoded image is bit-identical to the original. Achievable with PNG, WebP-lossless, and (technically) JPEG-LS, but not with standard JPG. Standard JPG cannot be re-encoded losslessly — every save loses some data.
- Visually lossless means a human can’t tell the compressed version from the original at normal viewing distance. This is what most "lossless JPG" tools actually do. Achievable, with care.
So the real question is: how do we make a JPG smaller while staying visually lossless? Five methods.
Method 1: mozjpeg / progressive re-encoding
Mozjpeg is a fork of the standard libjpeg encoder optimized for size. It uses smarter chroma subsampling, better quantization tables, and progressive scan ordering. The result: typically 15–30% smaller files at identical visual quality.
Tools that use mozjpeg under the hood: TinyPNG, Squoosh, ImageOptim, jpegoptim. Browser-based tools using WebAssembly mozjpeg: Squoosh and ShrinkTo.
SSIM in our test: 0.998–0.9995 (1.000 = identical). Visually indistinguishable from original.
File size: averaged 22% smaller across our 12 test photos.
Best for: any general JPG compression where you want the smallest file with no visible quality cost. This is the default we recommend.
Method 2: Quality 85 with high-quality resampling
The classic trick: re-encode at JPEG quality 85 (instead of the original’s 95–100). Quality 85 is the threshold above which most JPEG artifacts are below the human visual perception threshold for most photos.
This works because most photos are saved by cameras at quality 95–100, which preserves more detail than the human eye can resolve. Dropping to 85 removes redundant precision without removing visible information.
SSIM: 0.992–0.998. Indistinguishable from original at normal viewing.
File size: averaged 45% smaller.
Best for: photos that came directly from a smartphone or DSLR, which are nearly always over-encoded at quality 95+. Don’t use on photos that have already been compressed once — you’re stacking lossy compression on lossy compression and quality drops noticeably.
Method 3: Convert to WebP
WebP is a modern image format from Google with a stronger compression algorithm than JPEG. WebP can be either lossless or lossy. Lossy WebP at quality 85 produces a file that’s typically 30–40% smaller than the equivalent JPEG with similar visual quality. Lossless WebP can be smaller than the original JPEG’s decoded data, especially for photos with large smooth regions.
SSIM: 0.997–0.999 for lossy WebP at q=85.
File size: averaged 31% smaller than the source JPG.
Catch: not all platforms accept WebP uploads. Government portals, older CMSs, and many email clients reject WebP files. WordPress, Slack, modern web all support it. Check your destination first.
Best for: web publishing, modern app uploads, anything that consumes the image programmatically.
Method 4: Smart downscale + re-encode
If your photo is 4032×3024 px (typical 12 MP phone photo) but it’s only ever displayed at 1920×1440 px or smaller, the extra resolution is invisible to the viewer but doubles file size. Resize first, encode second.
The key word is "smart": use a high-quality resampling algorithm (Lanczos, bicubic) instead of the default browser nearest-neighbor. ShrinkTo defaults to Lanczos for downscaling, which preserves edge detail better than bicubic.
SSIM: not directly comparable (image is now smaller); subjective quality at displayed size is identical or better.
File size: averaged 70% smaller when downscaling from 4032×3024 to 1920×1440.
Best for: photos that will only be viewed at smaller sizes — web pages, social media, any context where the original full resolution is wasted.
Method 5: Strip metadata
Photos from modern cameras carry 30–200 KB of EXIF metadata: timestamp, GPS coordinates, camera model, focal length, exposure settings, embedded thumbnail. None of this affects how the image looks. Stripping it gives you a smaller file with bit-identical visual output.
SSIM: 1.000 (truly lossless — pixel data unchanged).
File size: averaged 8% smaller. Higher savings on photos with embedded thumbnails.
Best for: any image where you don’t need the metadata. Bonus: removes GPS coordinates, which is a privacy win when sharing photos publicly.
Combining methods
The most aggressive "visually lossless" approach combines all five:
- Strip metadata (tiny win, no quality cost)
- Smart-resize to actual display size (large win)
- Re-encode with mozjpeg at quality 85 (medium win)
Combined savings on our 12-photo test set: 78% smaller file with SSIM still ≥0.995 against original at the new (smaller) size. ShrinkTo runs all three in sequence when you use the "Auto" output format with a target KB.
When "visually lossless" isn’t good enough
Some specific use cases need the original or as close to it as possible:
- Print photography at 300+ DPI — print can resolve detail that screens can’t. Use the original; don’t re-compress.
- Forensic / archival — legal admissibility may require unmodified originals. Keep the original separately.
- Photo editing — multiple save cycles compound JPEG quality loss. Edit in PNG or TIFF, export to JPG only at final save.
- Stock licensing — buyer may need the largest available size. Don’t pre-compress submissions.
How to do this with ShrinkTo
- Open shrinkto.com and drop your JPG.
- Either: set output format to "Auto" and a target KB — engine picks the best combination of methods to hit your target with maximum quality.
- Or: enable auto-resize and set max dimension to the size you actually need (e.g., 1920 px for web).
- Click compress. Output is mozjpeg-encoded with stripped metadata, automatically.
Method comparison (12-photo average)
| Method | File reduction | SSIM (vs original) | Visible quality cost |
|---|---|---|---|
| mozjpeg re-encode | 22% | 0.998 | None |
| Quality 85 re-encode | 45% | 0.995 | None to barely perceptible |
| Convert to WebP q=85 | 31% | 0.998 | None |
| Smart downscale to 1920px | 70% | n/a (smaller) | None at display size |
| Strip metadata | 8% | 1.000 | None (bit-identical pixels) |
| All combined | 78% | 0.995 | None at display size |
Try the visually-lossless workflow. Drop a JPG into shrinkto.com, set "Auto" format, and let the engine pick the best combination of methods. Result: 60–80% smaller files that look identical to your eye, free, in your browser.
Frequently asked questions
Can JPG be compressed losslessly?
Strictly speaking, no — re-encoding a JPG always introduces some additional loss because the format is lossy by design. But "visually lossless" compression (where the difference is imperceptible to a human) is fully achievable, typically saving 20–30% with mozjpeg or quality-85 re-encoding. SSIM scores stay above 0.99 in this range.
What's the best quality level for JPG to balance size and quality?
Quality 85 is the consensus sweet spot. Below 80 you start seeing JPEG blocking artifacts in smooth regions like skies or skin. Above 90 you save very little file size for invisible quality gains. Quality 85 typically halves the file size from a quality-95 source with no visible cost.
Should I use mozjpeg or just standard JPEG?
Mozjpeg if your tool offers it — it gives 15–25% smaller files at identical visual quality compared to standard libjpeg. Squoosh, TinyPNG, and ShrinkTo all use mozjpeg under the hood. Standard libjpeg is a reasonable fallback but consistently larger.
Is converting JPG to WebP worth it?
For web publishing: yes, almost always. WebP at quality 85 produces files 25–35% smaller than the equivalent JPEG with similar visual quality. Caveat: not every destination accepts WebP. WordPress, modern browsers, Slack, and most apps work fine. Government portals, older CMSs, and some email clients reject it.
Does compressing JPG remove image quality each time I save?
Yes — every JPEG save introduces additional loss because the file is decoded, modified, and re-encoded. After 4–5 cycles the cumulative loss becomes visible. Best practice: keep the original, edit non-destructively, export to JPG only once at the final stage.
How can I make a JPG smaller without changing pixel dimensions?
Three options that don't touch dimensions: (1) re-encode with mozjpeg, (2) drop quality to 85, (3) strip EXIF metadata. Combining all three saves 30–50% of file size with no perceptible quality loss and no resolution change.
What does SSIM mean in image compression?
SSIM (Structural Similarity Index) measures perceived quality difference between two images on a scale of 0–1. 1.0 means identical, 0.99 means imperceptible difference, 0.95 means slight quality loss visible on close inspection, below 0.90 means visible degradation. Modern compression tools target SSIM ≥ 0.99 to claim "visually lossless".
Should I strip EXIF data from photos before publishing online?
Yes for privacy — EXIF often contains GPS coordinates revealing where the photo was taken. Yes for file size — saves 8–15% typically. Keep an unmodified original archive if you need EXIF for personal records (camera settings, dates, locations).