Image Compress — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About Image Compress
Image compression is the trade between 'as small as possible' and 'still looks right'. Nearly every blurry upload, slow page, or over-quota email is a compression mistake somewhere — usually the wrong format for the content, not the wrong quality slider. Here's how to pick the right one.
Lossless formats (PNG, WebP-lossless, lossless-AVIF) preserve every pixel exactly but have a hard floor on file size. PNG in particular is optimised for solid colour regions and sharp edges — screenshots, icons, line art, UI captures. For a 1920×1080 photograph, PNG will produce a 2-4 MB file where a JPEG of the same photo at 85% quality is 200-400 KB with no visible difference. Using PNG for photos is the single most common 'why is this image 8 MB' mistake.
Lossy formats (JPEG, WebP-lossy, AVIF) discard perceptually-irrelevant detail to shrink. JPEG uses 8×8 block DCT with adjustable quality — 85 is the sweet spot where compression artefacts become invisible to most viewers and the file is ~10× smaller than a PNG. WebP (Google, 2010) typically saves 25-35% over JPEG at equivalent quality. AVIF (2019, AV1-derived) typically saves another 30-50% at equivalent quality but takes 10-30× longer to encode. For 2026, the rule is: photos → JPEG (universal) or AVIF (modern sites), graphics/screenshots → PNG or WebP-lossless, animations → WebP or APNG (GIF is worse than either).
One more: re-compressing a JPEG loses quality every time because the block grid shifts and the discarded high-frequency detail can't come back. Save originals, compress once from the source.
JPEG's 'quality' parameter controls two things simultaneously: the quantisation matrix (how aggressively to round DCT coefficients) and chroma subsampling (whether to store colour data at half the luminance resolution). Between quality 60 and 85, file size typically changes by 60-80% while visual quality changes very little — the eye is much more sensitive to brightness detail than colour. Above 90, file size balloons for subtle fidelity gains that only show on retina-grade screens at close viewing distance. Below 60, blocking artefacts become obvious in smooth gradients (sky, skin).
Quality 85 with 4:2:0 chroma subsampling is where every serious pipeline lands because it matches the visual system's actual discrimination: the Weber–Fechner threshold for human image-quality perception sits around 1-2% JPEG quantisation error, which 85 delivers. Magazine printing, stock photography, and Instagram all compress around this value.
For web delivery, serve the image at the actual display size (don't send a 4K image to a 400-pixel-wide blog post) and compress after resize. Resize alone usually gives a bigger file-size win than any quality-slider adjustment — a 4000-wide photo scaled to 1600-wide is already 6× fewer pixels before any compression.
Why does the output look worse than my source?
Two usual causes: (1) you used a lossy format on a graphic with sharp edges — JPEG produces visible 'ringing' around text and icons; try PNG or WebP-lossless instead. (2) Quality is set below 75 — artefacts become visible first in smooth gradients (sky, skin, gradients). Bump to 85 and re-export.
How does this compare to TinyPNG?
TinyPNG uses pngquant-like palette reduction for PNGs (great for 24-bit photos saved as PNG) and MozJPEG on the server for JPEGs. This tool uses the browser's native Canvas encoder — less aggressive on PNG, competitive on JPEG at quality 80-85. The trade-off is privacy: TinyPNG uploads every file to their servers; this tool doesn't upload anything.
Should I use WebP or AVIF in 2026?
WebP is universally supported (Safari added it in 2020; every browser has it now). AVIF has 90%+ browser support but encoding is slow and some CMSes still strip it. Default: WebP for web where every kilobyte matters, JPEG for universal compatibility (email, legacy apps, print). AVIF when you control serving and can pre-encode at build time.
Can I go from JPEG to PNG to get 'better' quality?
No — converting JPEG → PNG freezes the existing JPEG artefacts into a larger file. The lossy information is already gone; PNG just records it losslessly at 4-10× the size. Always go back to the highest-quality source you have.
Why is the WebP file sometimes larger than JPEG?
WebP can lose to JPEG at quality ~90+ because its overhead (alpha channel metadata, more aggressive filtering decisions) starts to matter. WebP's dominant win is at quality 60-85 where it keeps the same perceptual quality as JPEG but 25-35% smaller. Above 90, use JPEG; below 60, use WebP.
Does compression strip EXIF/metadata?
This tool's default export strips EXIF, GPS coordinates, and camera metadata — a privacy win when sharing personal photos. If you need EXIF preserved (photography portfolio, legal evidence), keep the original; canvas-based browser compression intrinsically drops it.
What's the smallest I can get an image without looking bad?
Rule of thumb for web photos: target 100-200 KB per 1920×1080 image via JPEG quality 80-85 or WebP quality 75. Below 50 KB for a full-HD photo, visible artefacts appear in most content. For icons and UI chrome, SVG is almost always smaller than any raster format — check if your source is vector.