Free Image Compressor Online

How It Works

1. Select or drop one or more images above.
2. Adjust quality slider (lower = smaller file, more compression).
3. Images are compressed in your browser · nothing is uploaded.
4. Download compressed images individually or all at once.

Why Compress Images?

Large images slow down websites, increase bounce rates, and hurt your Google ranking. Compressing images reduces file size by 50-80% with minimal visible quality loss. This is essential for web developers, bloggers, e-commerce stores, and anyone who publishes content online. Smaller images also save bandwidth on mobile devices and improve Core Web Vitals scores.

What "image compression" actually means

Image compression covers two fundamentally different operations that share a name. Lossy compression, used by JPEG and lossy WebP, discards image data the human eye is unlikely to notice (subtle gradations in shadow detail, high-frequency noise, chroma subsampling for human-vision-tuned colour-vs-brightness ratios). The output is smaller than the input but cannot be reconstructed bit-for-bit. Lossless compression, used by PNG, GIF, TIFF-LZW, and lossless WebP, encodes the exact pixel data more compactly using algorithms like DEFLATE (LZ77 + Huffman). The output is smaller, and decompressing reproduces the original byte-for-byte. Which one is right depends on the image: photographs tolerate lossy beautifully because their content is full of texture the eye can't track at the pixel level; logos, screenshots, and graphics with sharp colour transitions demand lossless because every pixel is intentional.

Quality settings in a JPEG compressor (the slider on this tool, 10-100%) control the quantization tables applied after the DCT step. At quality 100 the tables barely round any frequency coefficients; at quality 50 they round aggressively. Higher quality means bigger files with finer detail; lower quality means smaller files with visible blocky artifacts in flat areas. The default of 60% sits in the sweet spot for web use: usually a 50-80% file-size reduction with no perceptible change on a typical screen. For print or large-display work, push to 80-90%. For thumbnails or email-friendly versions, 30-50% is fine.

For PNG, the "quality" slider doesn't apply in the usual sense because PNG is always lossless. What this tool actually does for PNG inputs is run a stronger DEFLATE pass than most authoring software (Photoshop, Affinity, Sketch) bothers with by default; that typically squeezes 5-25% off the file size with zero pixel change. The Format dropdown also lets you convert PNG to JPEG or WebP, which trades lossless for a much smaller file but loses transparency for JPEG output and (for photographic content) the lossless guarantee for WebP. The Max Width option resizes images during compression: a 4000-pixel-wide photo downsized to 1920 pixels saves 75% on raw pixel count before any compression even runs, so it stacks with the quality reduction.

How this tool works under the hood

The compression engine is browser-image-compression by Donald Wong (GitHub: Donaldcwl/browser-image-compression, MIT licence). It's a pure-JavaScript library, about 95 KB minified, that wraps three browser primitives: the File API for reading bytes, the Canvas API (or OffscreenCanvas when available) for decoding, resizing, and re-encoding JPEG/WebP images, and UZIP (a small DEFLATE library) for handling PNG without going through Canvas. When you drop an image, the browser hands the bytes to the library; the library chooses the path based on the input format and the requested output.

For JPEG and WebP inputs, the path is decode-to-canvas, optionally resize to the configured Max Width, then call canvas.toBlob(mimeType, quality/100). The browser's built-in JPEG or WebP encoder does the actual quantization and Huffman coding. Quality is your slider value divided by 100, passed as the second argument. For PNG inputs being kept as PNG, the library skips Canvas entirely (a Canvas round-trip would needlessly re-rasterize the lossless data) and instead runs UZIP over the IDAT chunks of the PNG file directly, with maximum compression effort. This is why PNG-to-PNG compression here is genuinely lossless: the pixel data never gets decoded and re-encoded, only the DEFLATE wrapping is tightened.

When OffscreenCanvas is supported (modern Chrome, Edge, Safari, Firefox), the heavy decode-resize-encode work runs inside a Web Worker, keeping the main UI thread responsive. You can drop a batch of 20 photos and continue to scroll the page while each one processes. On older browsers, the library falls back to the main thread, which still works but blocks the page during large jobs. The entire pipeline runs inside your tab. The library is loaded once from a CDN (about 95 KB minified) on first visit, cached afterwards. No file content ever leaves the browser. Open the Network tab in DevTools while you compress a batch and you will see the one-time library fetch but nothing else.

A brief history of image-compression formats

• DCT, 1972-1974. Nasir Ahmed proposed the discrete cosine transform as a method for image compression in 1972; the formal algorithm was published with T. Natarajan and K. R. Rao in 1974. This single mathematical transform sits underneath every JPEG, MPEG, and H.26x video file in the world today.
• JPEG, 1992. The Joint Photographic Experts Group (formed 1986) standardized JPEG as ITU-T T.81 / ISO/IEC 10918-1 in 1992. 8x8 DCT blocks, YCbCr colour with optional chroma subsampling, quantization tables tuned for human vision. The format that made the photo-rich web possible.
• PNG, 1996. Created at the IETF as RFC 2083 to replace GIF after Unisys's LZW patent claims threatened the open web. DEFLATE (LZ77 + Huffman) compression, always lossless, full alpha transparency, no patent encumbrance. The 3rd Edition spec (W3C, 2023) added HDR, APNG animation, and EXIF metadata officially.
• WebP, 2010. Google released WebP as a still-image format based on the VP8 video codec's intra-frame coding. Lossy WebP runs 25-34% smaller than JPEG at comparable visual quality; lossless WebP runs about 26% smaller than PNG. Adoption took a decade; by 2026 over 96% of browsers worldwide support it.
• AVIF, 2019. The Alliance for Open Media released AVIF as the still-image variant of the AV1 video codec. Roughly 50% smaller than JPEG at comparable quality. Browser support is now 95%+ but encoder support in everyday authoring tools (Photoshop, Word, Slack) lags. Squoosh and ImageMagick can produce AVIF today; most cameras and phones cannot.
• HEIC, 2017. Apple adopted HEIF/H.265-based HEIC as the iPhone's default photo format. About half the size of equivalent JPEG. Royalty-encumbered, so rarely served on the open web. Most online uploaders (including this tool) accept HEIC only after a desktop conversion to JPEG; that conversion is the everyday workflow for sending phone photos to a non-Apple recipient.

Supported Formats

• JPEG · Best for photos and complex images. Lossy compression with adjustable quality.
• PNG · Best for graphics, logos, and images with transparency.
• WebP · Google's modern format offering smaller files than JPEG/PNG at comparable quality.

Real-world compression workflows

• Blog and website images. A 2 MB JPEG straight from a phone camera vs a 250 KB compressed JPEG: identical to the human eye on a typical screen, but the smaller file loads roughly 8x faster. Core Web Vitals (LCP) scores improve directly. Most pages with multiple photos see the largest Lighthouse performance gains from image compression, not from JavaScript or CSS optimization.
• Social media uploads. Instagram, Twitter, Facebook, LinkedIn all re-compress images on upload using their own algorithms. Compressing first gives you control over what gets sacrificed; uploading raw photos means the platform makes those choices for you, often with visible degradation.
• Email attachments. Most providers cap attachments at 25 MB per message (Gmail, Outlook, Apple Mail). Compressing a folder of photos from ~50 MB to ~10 MB lets you send everything in a single email instead of splitting across multiple sends or moving to a cloud-share link.
• E-commerce product photos. Product catalogues with hundreds or thousands of photos see large CDN bandwidth bills and slow page loads. Compressing the entire library cuts both. Shopify, Etsy, and Amazon sellers commonly compress before upload to lower hosting costs and improve search ranking.
• Screenshot-heavy portfolios. UI design portfolios are PNG-heavy because screenshots have sharp colour transitions where JPEG artifacts would be visible. PNG-to-PNG via tighter DEFLATE typically saves 10-20% with zero pixel change, useful for designer portfolio sites that need to stay fast without sacrificing rendering quality.
• Archival downsizing. A 12 megapixel photo from a phone is overkill for a family-share album that will only ever be viewed on screens. Resize to 4 megapixels at 80% quality: the result looks identical on every device that will ever see it, and the archive shrinks to a fifth of the original size. The originals stay safe on the source disk; the compressed versions go to the share or backup.

Common pitfalls and what they mean

• Recompressing a JPEG multiple times degrades it. Each JPEG save re-runs the DCT quantization step, losing detail you can never recover. The losses are subtle on the first pass and obvious by the third or fourth. Always compress from the highest-quality source you have (the original camera file, the export from your design tool), not from a previously-compressed JPEG you saved last week. If you need to make adjustments, keep a master copy in PNG or TIFF.
• PNG-to-JPEG drops transparency. JPEG simply has no alpha channel in the format spec. Any transparent pixels become solid white (or whatever your encoder substitutes) when you convert PNG to JPEG. For logos, icons, screenshots with transparent backgrounds, or any graphic with an alpha channel, stay in PNG or move to WebP, both of which preserve transparency.
• JPEG-to-PNG makes the file bigger. PNG's DEFLATE compression is great at smooth gradients and large solid areas, terrible at the high-frequency noise patterns JPEG compression leaves behind. Converting a JPEG to PNG often doubles or triples the file size with no quality gain. If you need lossless from a JPEG, you're already too late: the original information is gone. The conversion makes sense only if you specifically need PNG's transparency or a tool that won't accept JPEG.
• EXIF metadata is stripped by default. The browser-image-compression library defaults to discarding EXIF metadata (camera info, GPS coordinates, capture date, ICC colour profile) during recompression. For web use that's usually a feature (GPS coordinates leaking is a real privacy problem). For photographers archiving with metadata intact, this tool isn't right; use a desktop compressor like ImageOptim or jpegtran with the explicit "preserve metadata" flag.
• Colour profiles may not survive. An embedded ICC colour profile (sRGB, Adobe RGB, ProPhoto) tells displays how to interpret the pixel values. Canvas-based re-encoding may discard the embedded profile and tag the output as sRGB. For ordinary screen use this is fine because almost everything is sRGB anyway. For print-prep work, colour-managed photo prep, or wide-gamut deliverables, use a colour-aware tool (Photoshop's Export As, Affinity, RawTherapee) that explicitly preserves profile data.
• Very large images can crash a mobile browser tab. Decoding an image to Canvas needs RAM proportional to its dimensions: a 24-megapixel photo (6000x4000 pixels) needs about 96 MB just for the RGBA pixel buffer, plus working memory for the encoder. Mobile devices with 4 GB RAM may have the tab terminated by the OS before the encode completes. Resize the input or use a desktop browser for very large photos.

Privacy: images stay on your device

Every cloud image compressor (TinyPNG, Compressor.io, Optimizilla, Smallpdf's image tools, Pixlr's compress endpoint, the dozens of "compress image online" services) uploads your file to the operator's servers, runs their compression algorithm, and returns the smaller image as a download. The privacy implications are non-trivial because photos routinely contain identifiable content: faces, addresses visible in backgrounds, screenshots of internal UIs or confidential documents, photos of children, photos taken in private spaces. Most operators publish privacy policies committing to delete uploads within an hour or two and to encrypt in transit, and the bigger ones (TinyPNG, Smallpdf) hold ISO/IEC 27001 certification. They have strong commercial reasons to honour those policies. But "deleted within an hour" is not "never seen." During that hour the image content sits in the operator's infrastructure, accessible to any process or person with appropriate access, and visible in logs and backups according to whatever retention policy applies.

This compressor never uploads anything. The browser-image-compression library runs entirely in your tab; image bytes are read by the File API, processed in JavaScript (or in a Web Worker if OffscreenCanvas is available), and the compressed output is returned to the same tab as a downloadable Blob. You can verify there's no upload by opening the browser developer tools to the Network tab before compressing a batch: no requests fire that include your image content. The only network traffic is the one-time library fetch (~95 KB) from the CDN on first visit, after which the library is cached. Switch the browser to airplane mode after the page loads and the compressor continues to work on local files. For photos with anything sensitive (faces, locations, internal screenshots), the browser-side trade is clearly worth making.

When another tool is the right choice

• Batch processing 500+ images in a scripted pipeline. Use sharp in Node.js (the canonical server-side image library), ImageMagick or GraphicsMagick on the command line, or Pillow in Python. These tools handle thousands of files without browser-memory limits and run from CI jobs, deploy hooks, or cron tasks.
• Strict lossless guarantees with verifiable bit-equality. For PNG-to-PNG, this tool is genuinely lossless because UZIP doesn't touch the pixel data. For workflows that demand cryptographic verification (medical imaging, legal evidence), use a desktop tool like ImageMagick with explicit `-define png:compression-level=9` and SHA-256 verification of the decoded pixel data.
• Print-grade colour profile preservation. Adobe Photoshop, Affinity Photo, or RawTherapee for print-prep work with ICC profile preservation, soft-proofing, and CMYK output. Browser-based compression cannot guarantee colour-managed workflows because Canvas operates in sRGB and may strip embedded profile data.
• AVIF output for next-generation compression. browser-image-compression doesn't output AVIF as of 2026. For AVIF encoding in the browser, use Squoosh (also Google, also client-side); for command-line AVIF, use avifenc from libavif. AVIF produces files roughly 50% smaller than JPEG at comparable quality, but the encoder is computationally expensive (10x slower than JPEG encoding).

Frequently Asked Questions

Does compression reduce image quality?

At the default 60% quality, most images look nearly identical to the original while being 50-80% smaller. Adjust the slider to find the right balance for your needs.

Is there a file size limit?

Each image can be up to 50 MB. Since processing happens in your browser, very large files may take a moment depending on your device.

Are my images uploaded to a server?

No. All compression happens locally in your browser. Your images never leave your device, making this completely private and secure.

What quality setting should I use?

For web use, 60-70% is ideal. For print or portfolios, try 80-90%. For maximum compression (thumbnails, email), 30-50% works well.

More frequently asked questions

Why is my PNG output only a little smaller than the original?

PNG is lossless. The savings come entirely from finding a tighter DEFLATE compression of the same pixel data, which typically saves 5-25% over what an authoring tool (Photoshop, Sketch, Figma) wrote by default. If your PNG was already well-optimized, there's not much room left. To get meaningful additional reduction, either convert to WebP (which keeps transparency and is typically 25% smaller than PNG) or accept some loss by converting to JPEG (which can be much smaller but drops transparency).

Does this tool work offline?

After the first visit, yes. The browser-image-compression library (about 95 KB minified) is cached by the browser on first load. Subsequent visits to the compressor work entirely offline, as long as the browser cache has not been cleared in the meantime. You can verify by enabling airplane mode after opening the page once and compressing a local image.

Will my EXIF data (camera, GPS, capture date) be preserved?

No, EXIF metadata is stripped during compression by default. For web sharing this is usually desirable (GPS coordinates and camera serial numbers shouldn't leak), but for photographers archiving with metadata intact this tool isn't right. Use a desktop EXIF-aware compressor like ImageOptim (macOS) or jpegtran with the `-copy all` option to preserve metadata.

What's the difference between Max Width resize and quality reduction?

Resizing changes the pixel dimensions of the image: a 4000x3000 photo resized to 1920x1440 has 75% fewer pixels to encode, which cuts file size before any compression even runs. Quality reduction (the slider) controls how aggressively the JPEG or WebP encoder rounds its DCT coefficients, which makes the encoded data smaller per pixel. The two stack: resize first to drop overall pixel count, then quality-reduce what remains. For a typical "make this web-friendly" workflow, set max width 1920, quality 70, and the output is roughly 10-15% of the original size.

Can I compress HEIC images from my iPhone?

Browser support for decoding HEIC is limited (Safari on Apple devices does it; Chrome and Firefox don't). On non-Apple browsers this tool will reject HEIC files. The workflow for iPhone photos is to either change the iPhone setting (Camera → Formats → Most Compatible) to save JPEGs directly, or convert HEIC to JPEG once on a Mac or with a dedicated tool, then run those JPEGs through this compressor. iCloud's "Share via" sheet typically converts to JPEG automatically when sharing to non-Apple recipients.

Is there a desktop or command-line equivalent?

Several. For batch automation, sharp in Node.js is the standard server-side library and produces near-identical output. ImageMagick (magick input.jpg -quality 70 output.jpg) and GraphicsMagick handle huge files and run from any shell. jpegoptim and optipng are specialized JPEG and PNG re-encoders that often squeeze a few extra percent versus generic tools. For one-off interactive work like this tool but with more controls, Squoosh (Google Chrome Labs, also entirely client-side) supports a wider range of formats including AVIF.

Related Tools