Image Compressor

No — our compressor preserves the original pixel dimensions (width × height). It only reduces file size by re-encoding at a lower quality setting. If you need to resize, use a separate tool first.

Yes, 20MB per file. This covers virtually all photos from modern smartphones and DSLRs. For larger files (e.g., RAW camera output), convert to JPEG/PNG first.

Absolutely! The format dropdown lets you choose any output format regardless of input. For example, compress a PNG screenshot into a much smaller WebP file for your documentation site.

PNG uses lossless compression — it cannot discard detail like JPEG. If you set a high quality value on a PNG, the output may actually be slightly larger. For maximum PNG savings, consider converting to WebP instead.

70-80% is the sweet spot for most web images — visually near-identical to the original on screen but 60-80% smaller. Use 85% for hero images and photography portfolios, and 60% for thumbnails or icons where detail matters less. The side-by-side preview lets you compare original vs. compressed before downloading, so you can dial in the right balance for your use case.

Yes — it's perfect for README images. GitHub repos with large screenshots slow down page loads and eat into your LFS bandwidth. Drop your screenshot into the compressor, set quality to 70% and format to WebP, and you'll typically get a 80-90% size reduction with no visible quality loss at README display sizes.

Yes! Once the page is loaded, the compressor works entirely offline — no internet required. All image processing runs locally via the Canvas API, so it works on planes, in remote areas, or on metered connections. The tool page itself is ~20KB, so it loads instantly even on 2G/3G.

Currently, the tool processes one image at a time for simplicity and speed. For batch workflows, open multiple browser tabs — each runs independently and processes locally. Alternatively, use a command-line tool like ImageMagick or sharp for scripted batch compression.

Lossy compression (JPEG, or WebP at lower quality) permanently discards image detail to shrink file size — ideal for photos, but re-saving the same file repeatedly gradually degrades quality. Lossless compression (PNG) keeps every pixel intact, so files stay larger but quality never degrades. Rule of thumb: use lossy for photos and page backgrounds, lossless for logos, screenshots with text, and anything with sharp edges or transparency. Our tool lets you pick either per image via the format dropdown, so you can compare both outputs side by side before downloading.

No — the Canvas API strips all EXIF metadata, including GPS coordinates, camera model, timestamps, and color profiles. This is actually a privacy feature: your compressed image won't leak where or when the photo was taken. If you need to preserve metadata (for photography portfolios), use a desktop tool like ImageOptim or Squoosh instead.

Browser support for Apple's HEIC format is still limited, so this tool accepts JPEG, PNG, and WebP only. Two quick fixes: convert the HEIC to JPEG first (the Photos app's Export/Share menu does this in one tap), or change your iPhone to save photos in "Most Compatible" format — Settings → Camera → Formats → set Camera Capture to "Most Compatible" (JPEG instead of HEIC). The JPEG will compress exactly like any other photo here.

Not at the click of a button — there's no "set target size" switch, because output size depends on how much detail your specific image contains. The practical loop takes about 10 seconds: compress at 75%, look at the output size shown next to the download button, then drop quality by 5–10 points and repeat until you're under budget. If you're still too large, switch the output format to WebP first — that alone often saves 25–35%. For strict size limits (application uploads, for example), a two-pass approach is normal even in desktop tools.

SVG is a vector format — it stores shapes and paths as text, not pixels — so there's nothing for a raster compressor to re-encode. The browser preview you'd be compressing is a rendered bitmap, which would defeat the point of SVG (infinitely sharp at any size). For icons and logos, keep the SVG and shrink it by minifying the markup instead: strip editor metadata, comments, and unnecessary decimals with SVGO. If you truly need a raster version for a hero image or social card, open the SVG in a browser or design tool, export it as PNG at the size you need, then run that PNG through this compressor.

Yes. max-width and object-fit only change how many pixels get painted — the browser still downloads the full-resolution file first. A 4000px phone photo dropped into a 600px card still costs every visitor the full few megabytes, so it hurts Largest Contentful Paint exactly as much as an oversized image on a full-width layout. Treat CSS as layout, and this tool as the fix for transfer size: resize to roughly twice the largest width the image is displayed at (that covers retina displays), then compress.

Work backwards from the rendered box: a full-width hero is usually 1440–1920px on desktop, an in-article image 800–1200px, a card thumbnail 400–600px. Then double the smaller of those numbers if the image appears on high-DPI screens — a 600px card wants a 1200px file, not a 4000px one. Export at that width, run it through the compressor at 75–80%, and use srcset with width descriptors when the same image renders at several sizes so each device gets the smallest file that still looks sharp.

Because JPEG has no alpha channel. When a transparent PNG is re-encoded as JPEG, every fully transparent pixel has to become an opaque color — most encoders fill it with black (some use white). Nothing is "broken"; the format simply cannot store transparency. Keep the output as PNG or WebP whenever the image sits on a colored or patterned background, and only convert to JPEG if that background is already a flat, known color you're happy to hard-code.

JPEG is tuned for photographs, not for sharp edges. It drops color detail first (chroma subsampling) and then blocks the remaining detail into 8×8 tiles, which is exactly the wrong trade for UI text, thin borders, and terminal output. For screenshots, code snippets, and diagrams, keep PNG or switch to WebP at a high quality — those formats preserve hard edges. If you must ship JPEG, compress screenshots at 85–90% and at the exact display size, because any post-compression scaling re-blurs the text.