Online Image Compressor

Compress JPG, PNG, WebP, and GIF files in your browser. Preview the result, then download. Files are deleted within 5 minutes.

🖼️

Click to upload or drag and drop an image

JPG, PNG, WebP, GIF — up to 10 MB and 12.5 megapixels (4032 × 3024)

Lower = smaller file. This is not a direct percentage of size reduction.

About this tool

Large images slow websites, cost bandwidth, and hurt conversions. Google's Core Web Vitals rank pages partly on image weight, and a one-second delay on mobile costs measurable engagement. This tool reduces JPG, PNG, WebP, and GIF file sizes using PHP's GD library and well-established algorithms: JPEG's discrete cosine transform with adjustable quantization, PNG's DEFLATE with zlib, WebP's VP8 (lossy) and VP8L (lossless), and GIF's Lempel-Ziv-Welch (LZW). EXIF orientation flags are applied to pixels so mobile photos display upright everywhere, and ICC color profiles are preserved by default.

Your image is uploaded to our server, processed in a few seconds, and stored with a per-session URL that requires both your browser's session cookie and a one-shot HMAC token. The HMAC binds the URL to your specific session and to a five-minute expiry. The file is removed when you make a new upload, when your browser session ends, or at the latest five minutes after upload — whichever comes first. We never index or analyze uploaded images.

Why the size limits?

Uploads are capped at 10 MB and 12.5 megapixels, with no single side over 20,000 pixels. The cap is on total pixels rather than on each side, because that is what decoding actually costs: GD allocates four bytes per pixel for a truecolor buffer, so a 4000×500 strip (8 MB) is cheaper than a 2000×2000 square (16 MB) despite the longer side. A 12 MP photo (4032×3024) peaks at about 126 MB of resident memory while decoding, or 175 MB when an EXIF-rotated photo is turned upright, because that step briefly holds the source and destination buffers at once. Our hosting plan allows 512 MB across every process on the account and at most four concurrent PHP workers, so 175 MB per request leaves room for a second simultaneous upload with margin to spare. The cap also serves as the only practical defense against decompression bombs — a 1 MB PNG can expand to gigabytes of pixels, which no file-size limit can catch. Both limits are checked in your browser the moment you pick a file, so an oversized image is rejected immediately instead of after the upload finishes.

Lossy vs lossless compression

JPEG and WebP are lossy: they discard visual detail that humans struggle to perceive, achieving 50–80% file-size reductions at the cost of slight blurring on close inspection. The quality slider controls the quantization tables that govern the trade-off. PNG and GIF are lossless: every pixel is preserved exactly, so reductions are smaller (typically 5–30%) but the output is bit-identical to the input. Use lossy for photographs, lossless for screenshots, UI elements, and logos.

Format guide

  • JPEG/JPG: the universal photographic format. Uses DCT-based lossy compression with adjustable quality. Supports progressive rendering (encoded with imageinterlace() in our pipeline). Best for photos, not suitable for transparency.
  • PNG: lossless format with full alpha-channel transparency. Uses DEFLATE compression via zlib. Ideal for UI elements, logos, screenshots, and graphics with text. Larger than JPEG for photographic content.
  • WebP: Google's modern format offering 25–35% smaller files than JPEG at equivalent quality. Supports both lossy and lossless modes plus transparency. Supported by 96%+ of browsers as of 2024 and is the recommended default for new web projects.
  • GIF: limited to 256 colors per frame. Supports animation and 1-bit transparency. Compression is modest due to the format's age. Best for simple animations; use WebP for animated content where supported.

Choosing a quality slider value

Quality 1–100 maps to the JPEG/WebP quantization tables, where lower values mean coarser quantization and smaller files. Practical ranges:

  • 90–100 — visually indistinguishable from the original for most subjects; safe for portraits and product photos. File reduction is modest (10–25%).
  • 75–89 — the sweet spot for most web use. 30–60% reduction with quality indistinguishable at normal viewing sizes.
  • 60–74 — noticeable artifacts in smooth gradients (sky, skin) but acceptable for thumbnails and busy backgrounds. 50–75% reduction.
  • 40–59 — visible compression artifacts at full size; only for previews and explicit low-bandwidth contexts.
  • 1–39 — heavy artifacts; useful only for thumbnails under 200 px or proof-of-concept work.

EXIF orientation and color profiles

Mobile phone photos carry metadata that often trips up image processing: EXIF orientation flags, ICC color profiles, GPS coordinates, camera model, and timestamp. Most desktop viewers ignore orientation flags and rely on the actual pixel layout; many web browsers and image libraries apply the flag, which means a phone photo and its compressed copy can appear rotated differently across platforms. This tool reads the EXIF orientation flag, applies it to the pixels, and strips non-essential metadata. The result is a file that displays consistently everywhere.

ICC color profiles are preserved by default. If you compress an image with an embedded Adobe RGB profile and a viewer that does not understand the profile, colors may look washed out. For web use, sRGB is the safest profile because every browser and platform supports it. The trade-off is that very wide-gamut displays (recent MacBook Pro, high-end iPhones) will render sRGB images with slightly less saturation than the original capture intended.

Impact on web performance

  • Google's Core Web Vitals use Largest Contentful Paint (LCP) as a key metric — optimized images directly improve LCP scores.
  • Smaller images reduce server bandwidth costs and Content Delivery Network (CDN) transfer fees.
  • Mobile users on limited data plans benefit significantly from compressed images.
  • Social media platforms (Facebook, Twitter, Instagram) compress images further — optimize before uploading to retain quality.
  • E-commerce sites see measurable conversion improvements from faster-loading product galleries.

Common mistakes

  • Compressing an already-compressed image. Each pass loses information. Start from the original camera or design output, not from an Instagram-downloaded version.
  • Using lossy compression on PNG transparency. JPEG does not support alpha channels and will produce a solid background where the PNG had transparency. Use WebP or convert transparency to a known background color first.
  • Compressing images that are already small enough. A 20 KB JPEG will not compress meaningfully; the algorithm may even produce a larger output. Our tool detects this and falls back to the original.
  • Upscaling a small image and then compressing. Upscaling adds no information, so you are encoding noise. If you need a larger image, find a higher-resolution source.
  • Saving the same file repeatedly at quality 100. Quality 100 still re-encodes; use the original if no compression benefit is needed.
  • Ignoring file format choice. Format matters more than quality slider. A photograph should be JPEG or WebP, not PNG. A logo or screenshot with text should be PNG or WebP lossless, not JPEG.

FAQ

Why is my image sometimes larger after compression? For very small or already-optimized files, re-encoding adds overhead without removing data. Our tool detects this and returns the original file rather than a larger compressed copy. If you need the absolute smallest file, lower the quality slider or convert to a more efficient format (JPEG → WebP usually saves another 25–30%).

Is my uploaded image stored on the server? Only briefly, for the few seconds it takes to process. Files are stored with cryptographically random filenames, bound to your browser session, served only through our download proxy, and deleted automatically after 5 minutes. We do not index, analyze, or share uploaded images. See our Privacy Policy for details.

What's the largest image I can compress? 10 MB and 12.5 megapixels — that covers a 4032×3024 phone photo and a 1440×7200 stitched screenshot. No single side may exceed 20,000 pixels. Anything larger is rejected in your browser as soon as you select it, so you never wait through an upload that cannot succeed. For a 24 MP DSLR frame or anything bigger, resize it first with a desktop tool like ImageMagick or libvips — for web use you almost certainly want it under 2000 px on the long edge anyway.

Why isn't AVIF supported yet? AVIF (AV1 Image File Format) is the next-generation image codec and offers 20–50% better compression than WebP at equivalent quality, but server-side encoding requires libheif or libavif, which is not installed in our shared-hosting PHP environment. AVIF support is on the roadmap; until then, WebP is the recommended modern format.