Image Compression Tool

Online image compression reduces image file size so pages load faster, uploads fit size limits, and shared files consume less bandwidth. Files are uploaded to ToolAct's conversion service, processed with server-side libraries (libvips / mozjpeg / libwebp), and the compressed result is downloaded back. Originals are deleted from the server immediately after the conversion completes - they are not archived and are not used for training. Depending on the format, compression may adjust quality, metadata, color information, and encoding details; a photo can become much smaller while still looking acceptable at normal viewing size. It fits blog images, product photos, social posts, support attachments, and drafts that do not need to preserve every original pixel. It is not the same as professional print preparation, so images meant for archives, large prints, or fine visual inspection should be checked after compression. Avoid uploading photos containing personal information, internal documents, or other sensitive material.

Image compression splits cleanly along the lossy/lossless boundary. Lossy formats (JPEG, WebP lossy) exploit human perceptual limits: the eye is far less sensitive to high-frequency chroma than to luma, so encoders throw away tiny color detail in 8x8 or 16x16 blocks without most viewers noticing. JPEG has used this DCT-based path since 1992; the modern alternatives are mozjpeg (~5-10% smaller than libjpeg at the same SSIM, slower encoder), libwebp (Google's VP8/VP8L image codec, 2010), and AVIF (Alliance for Open Media, AV1 intra, 2019). Lossless formats (PNG, GIF, WebP lossless) shrink bytes through entropy coding - LZ77 sliding-window dictionary plus Huffman or arithmetic coding - and never alter a single pixel. The pipeline used by this page is fully server-side. The browser packages each image into a signed multipart upload to ToolAct's compression endpoint (/image/compress). The server validates the request, hands the bytes to libvips - a high-performance, low-memory image processing library - which decodes the source, optionally resizes the long edge to bound the output dimensions, and re-encodes through mozjpeg for JPEG, libwebp for WebP, or libpng/oxipng for PNG. The encoded bytes are streamed straight back to the browser as the download response, and the temporary upload file is deleted from disk as soon as the response is flushed. There is no archival, no training pipeline, and no human review of the contents. JPEG quantization is the heart of the format: a quality of 90 keeps almost all DCT coefficients, 75 starts dropping mid-frequency ones (visible in red text on yellow), 50 is the obvious-JPEG zone where blocking artifacts appear on smooth gradients, and 25 produces visible posterization on faces. PNG compression sits on zlib (DEFLATE) levels 0-9; level 1 is fast but ships larger files, level 9 squeezes the last bytes from flat-color banners at the cost of CPU. EXIF, ICC profiles, XMP, and IPTC metadata are usually dropped because the encoder rebuilds the file header from scratch - a real reason a 200 KB camera photo can become a 60 KB upload even at the same resolution, and a reason image provenance and color-management metadata should be preserved separately if they matter.

• libvips (John Cupitt, LGPL) is the server-side image processing engine: a streaming, demand-driven pipeline that keeps memory use low even on 100 MP inputs and underpins Sharp, ImageMagick's IM7 vips delegate, and the conversion endpoints behind this tool.
• mozjpeg (Mozilla, libjpeg-turbo fork with better psychovisual models) produces 5-10% smaller files than stock libjpeg at the same SSIM but is roughly 3-5x slower to encode - the trade-off behind most JPEG-quality 80-85 web defaults since 2017.
• PNG is LZ77 + Huffman: the encoder finds repeated byte sequences up to 32 KB back (sliding window), emits (distance, length) pairs, then Huffman-codes the result. WebP lossless (VP8L) uses a similar idea plus Local Palette patches, typically beating PNG by 20-26% on the same RGBA pixels.
• libwebp is Google's reference WebP encoder/decoder; the server side uses it to write either lossy VP8 (quality 0-100, 4:2:0 chroma by default) or lossless VP8L (quality controls compression effort, never pixel fidelity). WebP decode is widely available (Chrome 32+ 2014, Firefox 65+ 2019, Safari 14+ 2020), so a converted WebP is safe for almost every modern browser.
• The 4:2:0 chroma subsampling default in JPEG (two chroma samples per 4 luma) is what makes red text on a yellow background look blurry at quality 60 - the chroma detail is dropped before the luma detail is. Switch to 4:4:4 (no subsampling) for screenshots and UI captures where text edges matter.
• EXIF (Exchangeable image file format, JEITA CP-3451) and ICC color profiles are stripped on re-encode by default, so a 6.3 MB iPhone JPEG often lands at 1.8 MB after the server touches it. That is the reason consumer photographers see file sizes drop after every round-trip through a web tool. A practical batch pitfall: when a folder mixes small icons (under 200x200 px, PNG with alpha), flat-color UI screenshots (PNG, very high compressibility), and phone photos (JPEG, mostly noise-like content), a single quality slider is wrong for all three. Icons want lossless PNG or WebP lossless; screenshots want 4:4:4 JPEG at quality 85-90; photos want lossy WebP at quality 75-80. Compressing them all at quality 60 saves bytes but introduces red fringing on icons, ringing artifacts around screenshots, and banding on the photos. The smarter pipeline runs each category through a different encoder path, which is why the API accepts a target format override per file even when the user picks one default. Looking forward, JPEG XL (ISO/IEC 18181, 2022) is the format Google and Cloudflare have been pushing since 2020 as the JPEG successor: ~20% smaller at the same quality, full lossless mode, no chroma subsampling, and a progressive decode friendly to slow networks. Browser support is partial (Chrome disabled JPEG XL in 110), so the practical migration path for now is WebP at quality 80, AVIF for hero assets that need the extra bytes, and keep a JPEG fallback for old Safari or older email clients. The page exposes quality, max dimension, and target format as the three levers that matter; everything else is implementation detail.
• Server-side conversion lifecycle: every uploaded file is held only long enough to run libvips decode + re-encode and stream the result back. The temporary file is deleted on response close, regardless of whether the conversion succeeded or failed. A 24 MP JPEG that would have stalled the renderer's main thread for 200-500 ms is processed off the user's device entirely.
• Migration: AVIF is the next-generation target (Alliance for Open Media, AV1 intra, supports 10/12-bit, alpha, animation). Server-side AVIF encoding via libavif/aom is still 10-30x slower than WebP, so most pages stick with WebP at quality 80 and reserve AVIF for hero photos that benefit from the extra 15-20% byte savings.