Image Compressor

• JPEG — photographic content. Lossy DCT-based compression. Tunable quality 0-100. Bad for sharp edges (creates ringing artifacts around text) and large flat areas (banding at low quality). The 1992 format is still ubiquitous.
• PNG — sharp-edged content with limited colors or transparency. Lossless. Good for icons, logos, screenshots of UI. Terrible for photos (file 10-20× larger than JPEG of the same quality).
• WebP — modern (Google, 2010). Both lossy and lossless modes. Roughly 25-35% smaller than equivalent-quality JPEG; 25% smaller than equivalent PNG. Supported in every modern browser since ~2020. Default choice for new content in 2026.
• AVIF — newer (2019). Even better compression (~50% smaller than JPEG at equivalent quality). Encoding is slow; browser support reached parity in 2023 but some image-processing pipelines do not handle it yet.
• GIF — only relevant for animations, and even there WebP and AVIF beat it. Limit to legacy compatibility.

• JPEG quality 100 — minimal lossy compression. File size is high; quality is best but still loses some chroma detail compared to a lossless source.
• JPEG quality 80-90 — sweet spot for most photographic content. Visually indistinguishable from the original on a typical screen for most images.
• JPEG quality 60-79 — visible artifacts on detailed content but acceptable for hero images, thumbnails, social media.
• JPEG quality < 60 — visible artifacts (blocking, ringing). Use only for ultra-low-bandwidth scenarios.
• WebP quality scale is nominally 0-100 but the underlying codec is different; quality 80 in WebP ≠ quality 80 in JPEG. WebP 75-85 typically matches JPEG 90.

Compressing a 4000×3000 photo to quality 80 still keeps it 4000×3000. If you only need it at 1600×1200 (because that is the display size), the right first step is to resize. A 1600×1200 JPEG at quality 85 is much smaller than a 4000×3000 JPEG at quality 30 — and looks better. Always resize to the actual display dimensions before compressing.

For responsive web: serve multiple sizes via srcset, not one giant image scaled by the browser. A 4K hero image scaled to 800px wide on mobile wastes bandwidth.

• You took a screenshot and want to share it without sending a 5MB file.
• You are writing a blog post and need to optimize hero images for fast page load.
• You inherited a website with a 30MB-per-page image budget and want to audit what compressing each image would save.
• You are emailing a contract or invoice scan and need to fit attachment size limits (Gmail: 25MB total; corporate mail servers often less).

• It will not OCR or edit your image. For text extraction, use the OCR tool; for cropping/filters, use the image editor.
• It will not produce HEIF/HEIC. Apple's HEIF format is patent-encumbered for encoding (decoding is free); browsers do not support it on the public web. Convert to WebP or AVIF if you need wider compatibility.
• It will not preserve EXIF metadata by default. Stripping EXIF (camera details, GPS coordinates) is the default — most users sharing photos online do not realize how much location data they would otherwise leak.