Image Compressor

Compress PNG, JPG, and WebP images directly in your browser. Files stay on your device and never get uploaded to a server. Reduce image sizes by up to 90% with no visible quality loss. Works as a private, free alternative to TinyPNG.

Key features

Up to 90% compression with no visible quality loss
Runs entirely in your browser on any device
Batch processing with one-click download
Smart algorithm balances file size and visual quality

Guide

Image compression reduces the file size of a photograph or graphic without removing enough visual detail for the average viewer to notice. This tool runs entirely in your browser using the Canvas API and, for PNG files, an optimized quantization algorithm. No image data leaves your device. The file you drop onto the page stays in local memory, gets re-encoded at the quality level you choose, and the smaller version is handed back to you as a downloadable blob URL. Understanding why file size matters is the first step. A single uncompressed photograph from a modern phone camera can weigh 5 to 12 MB. A product page with eight such images forces a visitor on a typical 15 Mbps connection to wait several seconds before the layout stabilizes. Google uses Largest Contentful Paint (LCP) as a Core Web Vital, and oversized hero images are the most common reason a page fails the 2.5 second threshold. Compressing those images to 100-300 KB each can cut total page weight by 90 percent and move your LCP into the green zone without any server-side infrastructure change. The relationship between file size and user behavior is well documented. Research from Google and Akamai shows that a one-second delay in page load reduces conversions by 7 percent. On mobile networks, where effective bandwidth can drop to 3-5 Mbps during congestion, image weight dominates total load time. A page with 4 MB of images takes over 6 seconds to fully render on a congested mobile connection. That same page with images compressed to 400 KB total renders in under 2 seconds. The difference translates directly into bounce rate, engagement time, and revenue for commercial sites. The tool supports three input formats: JPEG, PNG, and WebP. Each format uses a different compression model, and knowing the differences helps you pick the right quality setting. JPEG is a lossy format built on the Discrete Cosine Transform. It splits the image into 8x8 pixel blocks, converts them from RGB to YCbCr color space, applies DCT to each block, then quantizes the frequency coefficients. Lower quality values increase quantization, which discards more high-frequency detail. At quality 80 out of 100 most photographs lose no perceptible detail. At quality 60 you may start to see banding in smooth gradients and ringing around sharp edges. Below 40 the blocking artifacts become obvious on most screens. The YCbCr color space deserves a brief explanation. Y is the luminance (brightness) channel, and Cb and Cr are the blue-difference and red-difference chrominance channels. Human vision is far more sensitive to changes in brightness than changes in color. JPEG exploits this by subsampling the chrominance channels, typically at 4:2:0, which means the color information is stored at half the resolution of the brightness information in both dimensions. This single step reduces color data by 75 percent with minimal perceptible impact. When you set a higher quality level, the quantization tables preserve more frequency detail, but the chroma subsampling ratio usually stays the same. PNG uses lossless DEFLATE compression. The raw pixel data is first filtered row by row (sub, up, average, or Paeth prediction), then the filtered stream is compressed with zlib. Because no data is discarded, PNG files of photographs tend to be very large. The compression gain comes from reducing the color palette. A 24-bit PNG photograph with millions of unique colors can be converted to an 8-bit indexed palette of 256 colors. The tool does this palette quantization automatically when you move the quality slider below 100 for PNG inputs. At 256 colors the visual difference on most photographs is subtle, but the file shrinks by 60-80 percent. For graphics with flat color regions, such as logos or screenshots, PNG at full quality is already efficient, and even modest palette reduction produces significant savings. The palette reduction process uses a median-cut algorithm. It sorts all the unique colors in the image into a three-dimensional RGB cube, then recursively splits the cube along the axis with the greatest color range. After enough splits to reduce the palette to the target number of colors (e.g., 256), each pixel is mapped to the nearest palette entry. Dithering can be applied to reduce visible banding in gradients. Floyd-Steinberg dithering distributes the quantization error from each pixel to its neighbors, creating a pattern that simulates intermediate colors. The tool applies dithering automatically for quality settings that trigger palette reduction. WebP was developed by Google and supports both lossy and lossless modes. In lossy mode it uses VP8 video codec prediction, which is more efficient than JPEG DCT at the same perceptual quality. A JPEG at quality 80 typically matches a WebP at quality 75 in visual fidelity, but the WebP file is 25-35 percent smaller. The efficiency gain comes from VP8 using variable block sizes (4x4 to 16x16) instead of JPEG's fixed 8x8 blocks, and from using intra-frame prediction where each block is predicted from its neighbors before encoding the residual. In lossless mode WebP outperforms PNG by 10-25 percent through predictive coding of neighboring pixels and arithmetic entropy coding. Browser support for WebP is now above 97 percent globally, so it is safe to serve WebP to nearly all visitors. To use the tool, open the page and drag one or more images onto the drop zone. You can also click the area to open a standard file picker. The tool reads each file into an in-memory bitmap using the browser FileReader API and then draws it onto a hidden Canvas element. The quality slider maps to the second argument of the canvas.toBlob() method. For JPEG and WebP this is a float from 0 to 1 representing encoding quality. For PNG the tool first runs median-cut palette quantization at the selected level, then encodes the quantized pixel data. A preview of the compressed result appears immediately, along with the original size, new size, and percentage reduction. Batch processing works by queuing each dropped file through the same compression pipeline. Files are processed sequentially to avoid saturating the main thread. Each result appears in a list with its own download button. A "Download All" button packages every result into a single ZIP archive using the JSZip library, so you get one file instead of clicking eight separate links. Step-by-step workflow for a typical use case. Start with a folder of product photos exported from Lightroom at full quality JPEG. Open the compressor tool. Drag the entire selection of files onto the drop zone. Set the quality slider to 80. Wait for the batch to finish processing. Review the before-and-after previews by clicking on any thumbnail. If any image shows visible artifacts, select it and increase quality to 85 or 90 individually. Click "Download All" to get a ZIP. Upload the compressed images to your CMS or CDN. Common mistakes. The most frequent error is compressing an image that was already compressed. If you take a JPEG at quality 75, open it in an editor, export it at quality 80, and then run it through this tool at quality 80 again, you have three generations of lossy encoding. Each generation introduces its own quantization error. The artifacts compound, particularly around edges and in smooth gradient areas. Always start from the highest quality source you have. If you only have a pre-compressed JPEG, set the quality slider higher than you normally would (85-90) to avoid adding a thick layer of new artifacts on top of the existing ones. Another mistake is using JPEG for images with text or sharp line art. JPEG block-based encoding smears the edges of letterforms and creates visible halos around high-contrast boundaries. The effect is called Gibbs phenomenon or ringing, and it occurs because the DCT approximation of a sharp edge requires many high-frequency coefficients that get quantized away. For screenshots, diagrams, or logos, PNG or WebP lossless will produce a smaller file with perfect edges. The tool does not currently auto-detect content type, so you need to make this judgment yourself. A third mistake is ignoring image dimensions. Compression reduces encoding overhead, but it does not change the pixel count. A 4000x3000 photograph compressed to quality 60 may still be 800 KB. If that image displays at 400x300 on the page, you are sending 100 times more pixels than needed. Resize the image to its display dimensions first, then compress. The combination of resizing and compression often turns a 5 MB source into a 40 KB deliverable. A fourth common error is applying the same quality setting to every image regardless of content. A flat-color illustration compresses far more efficiently than a detailed texture photograph. The illustration might look perfect at quality 60, while the texture photograph needs quality 85 to avoid visible artifacts. Evaluate each image individually, or at least separate your batch into categories (photographs, graphics, screenshots) and use different quality settings for each. Advanced tips. When targeting WebP for a website, generate both a WebP version and a JPEG fallback. Use the HTML picture element with a source for WebP and an img fallback for JPEG. This way the 3 percent of browsers that lack WebP support still see an image. The tool can produce both versions from the same source in one session by running the batch once with WebP output and once with JPEG. For e-commerce, compress product images at quality 82-85 JPEG. This range consistently scores above 0.95 on the SSIM perceptual quality index while keeping file sizes under 150 KB for a 1200x1200 product shot. Below quality 80 you risk visible banding on white or pastel product backgrounds, which can make a product look cheaper than it is. Test compression on your actual product backgrounds. Pure white backgrounds are particularly unforgiving because any banding or color shift is immediately visible. For social media, platforms re-compress every image you upload. Uploading a pre-compressed JPEG at quality 70 means the platform applies its own quality 85 pass on top of your already lossy file, producing a double-compressed result. Upload at quality 95 or higher to give the platform a clean source. The recompression will bring the size down, and the result will look better than if you had pre-compressed aggressively. This applies to Facebook, Instagram, Twitter/X, LinkedIn, and virtually every social platform. Each platform uses its own compression pipeline with proprietary settings. Performance characteristics of the tool itself. Compression speed depends on image dimensions, not file size. A 4000x3000 JPEG takes about 200-400 ms to decode, draw to canvas, and re-encode in a modern browser. A batch of 20 such images takes 4-8 seconds. The bottleneck is the canvas toBlob call, which runs on the main thread in most browsers. During compression the UI may feel briefly unresponsive for very large batches. If you routinely compress hundreds of images, consider splitting them into batches of 20-30. Memory usage is proportional to the uncompressed bitmap size. A 4000x3000 image at 4 bytes per pixel (RGBA) consumes 48 MB of memory as a canvas bitmap. Twenty such images held simultaneously would need nearly 1 GB. The tool releases each bitmap after encoding to keep memory bounded, but if your browser tab approaches the per-tab memory limit (typically 1-4 GB depending on browser and OS), you may see a crash. Close other tabs before running large batches. Format comparison summary. JPEG: best for photographs, lossy only, no transparency, near-universal support, the default choice for photographic web content. PNG: best for graphics with sharp edges and flat colors, supports transparency, lossless (or lossy via palette reduction), larger than JPEG for photos, ideal for screenshots and UI elements. WebP: best general-purpose format, supports both lossy and lossless modes, supports transparency, 25-35 percent smaller than JPEG at equivalent quality, 97 percent browser support, the recommended format for new web projects. AVIF is a newer format with even better compression ratios (30-50 percent smaller than JPEG) but browser support is around 92 percent, and encoding is significantly slower, often 10-20 times slower than JPEG or WebP encoding. This tool does not yet support AVIF output. The privacy advantage of browser-based compression deserves emphasis. Cloud-based compression services upload your images to a remote server. For personal photos this means a third party stores your images, even temporarily. For business documents, product photos under NDA, or medical images, uploading to an external server may violate privacy policies or regulations like GDPR, HIPAA, or SOC 2 requirements. Because this tool processes everything in your browser, no network request leaves the page after the initial load. You can verify this by opening the browser Network tab and watching during compression. Zero outbound requests. This makes the tool suitable for handling sensitive images that cannot leave the local device. Integrating compression into a development workflow. Front-end build tools like Webpack and Vite have image optimization plugins (imagemin, vite-imagemin) that compress assets at build time. These are appropriate for static assets like logos, icons, and background patterns that ship with the application. For user-uploaded content, though, you need runtime compression. This tool uses the same Canvas API approach you would use in your own application code. You can replicate the compression logic in a React component by creating an OffscreenCanvas, drawing the user file to it, calling toBlob with the desired quality, and returning the result. Web Workers can move the encoding off the main thread if you need the UI to stay responsive during large batch operations. Testing compression quality objectively. The Structural Similarity Index (SSIM) compares two images and produces a score from 0 to 1, where 1 means identical. An SSIM above 0.95 is generally considered visually lossless for web content. At JPEG quality 80 most photographs score between 0.96 and 0.99 on SSIM against the original. Online SSIM comparison tools and the Python scikit-image library both provide this metric. Another useful metric is the Butteraugli score developed by Google, which measures perceptual difference and is used internally by WebP and AVIF encoders. If you are setting compression standards for a team, define a minimum SSIM threshold rather than a fixed quality number, because the ideal quality setting varies by image content. Responsive image strategy. Compression is one part of a broader image optimization pipeline. Serve different image sizes for different screen widths using the srcset attribute. Generate 3-4 size variants (e.g., 400w, 800w, 1200w, 2000w) and compress each at quality 80 JPEG or quality 75 WebP. The browser selects the smallest variant that fills the display area. Combined with compression, this approach routinely cuts image payload by 95 percent compared to serving a single full-resolution uncompressed file. The sizes attribute tells the browser how wide the image will display, and the browser uses this information plus the device pixel ratio to choose the appropriate srcset candidate. Lazy loading. Add loading="lazy" to images below the fold. This tells the browser not to fetch those images until the user scrolls near them. Lazy loading does not reduce file size, but it reduces initial page load time by deferring unnecessary network requests. Combine it with compression for maximum effect. The hero image should not be lazy loaded because it is usually the LCP element and needs to load as fast as possible. Compress the hero image aggressively (quality 75-80) and consider using a smaller intrinsic size for mobile viewports. Use fetchpriority="high" on the hero image to tell the browser to prioritize it over other resources. CDN and caching. After compressing your images, serve them through a Content Delivery Network (CDN) with long cache headers. Set Cache-Control to max-age=31536000 (one year) for images with content-based filenames (e.g., product-photo-a1b2c3.webp). This ensures repeat visitors load images from local cache instead of re-downloading. Some CDNs (Cloudflare, Cloudfront, Fastly) offer automatic image compression and format conversion at the edge. If you already use such a CDN, you may not need to pre-compress, but testing both approaches and comparing file sizes and visual quality is worthwhile. CDN auto-compression sometimes uses conservative settings that produce larger files than manual compression at a chosen quality. Running your own compression gives you full control over the quality-size trade-off. Accessibility. Compression does not affect alt text, ARIA labels, or other accessibility metadata. However, over-compression can reduce the effectiveness of images for users who zoom in on fine details. Product photos with small text (size labels, care instructions) should be compressed more gently (quality 85-90) to preserve readability at high zoom levels. Decorative images that convey no information can be compressed more aggressively. Images used as the sole carrier of information (infographics, charts, maps with labels) should be compressed conservatively and tested at 200 percent zoom to verify text remains legible. Measuring the impact. After deploying compressed images, re-run Lighthouse or PageSpeed Insights. Look at the "Serve images in next-gen formats" and "Efficiently encode images" audit items. Both should pass or show reduced savings. Monitor LCP in the Chrome User Experience Report (CrUX) for your domain to verify that the compression has improved real user loading times, not just lab scores. Track the p75 LCP value over time to see the trend. A successful compression effort typically moves LCP by 500-2000 ms on image-heavy pages. Image compression and SEO. Google has confirmed that page speed is a ranking factor, and Core Web Vitals (LCP, CLS, INP) are part of the page experience signals used in search ranking. Images are the largest contributor to LCP on most pages. Compressing images to meet the 2.5 second LCP threshold directly supports search ranking. Beyond speed, properly compressed images with descriptive filenames, alt text, and appropriate dimensions appear in Google Image Search results, which can drive significant traffic for visual products and content.

Frequently asked questions

Will the quality of my photos drop?

The compression algorithm reduces file size without visible differences. You control the quality level with a slider.

Is my privacy safe?

Yes. Your images are processed only in your browser and are never uploaded to any server.

Is WebRecast a free TinyPNG or Squoosh alternative?

Yes. WebRecast compresses images directly in your browser with no uploads, no account, and no limits.