Image compression is the process of re-encoding a picture so it takes fewer bytes to store or send. That is the plain answer to what is image compression: you shrink the file, either perfectly with no data lost (lossless), or by discarding detail your eye barely registers (lossy) for a much smaller result.
I build the compressor behind this site, so the mechanics below are what runs when someone drops a file on it. For the fuller menu of settings and near lossless routes, see the guide on how to compress images without losing quality. This page stays on the ground floor: what compression is, how it shrinks a file, and how much smaller it really gets.
What is image compression?
Image compression is a type of data compression applied to digital images to reduce their cost for storage or transmission (Wikipedia: image compression). Unlike zipping a text file, an image compressor can take advantage of how human vision works, so it beats generic file compression on photos.
Every photo starts as a grid of pixels, and each pixel stores a red, a green, and a blue value. A single 12 megapixel phone frame with no compression at all is 12,000,000 pixels times 3 bytes, which is 36,000,000 bytes, about 36 MB, for one picture. Almost nobody needs all of it at full weight.
Compression closes the gap between that raw number and a file a browser, a phone, or an upload form can actually handle. It does that in one of two fundamentally different ways, which is the first thing worth getting straight.
Why is image compression important?
Image compression is important because raw images are far too large to store and move at scale, and slow pages lose readers before the picture even appears. A page loaded with uncompressed photos can take seconds to render, and most people leave first.
Storage and bandwidth
Storage costs money at volume, and every byte you send costs bandwidth and time on both ends. A library of a few thousand uncompressed 36 MB frames is a serious bill; the same library at a few hundred KB each fits on a phone. Sending compressed images also means faster uploads, faster downloads, and less mobile data burned.
Page speed and rankings
Large images are the most common reason a web page feels slow, and page speed is part of how search engines judge a site. Getting a photo from several megabytes down to a few hundred KB, with no visible change, is usually the single biggest speed win available to a page. That is why image optimization sits near the top of almost every performance checklist.
What are the two types of image compression?
There are two types of image compression, lossless and lossy, and the line between them is not a matter of degree. One rebuilds your image exactly; the other gives it back changed but smaller. Everything else is a detail of how each one does its job.
| Property | Lossless | Lossy |
|---|---|---|
| Data on decode | Every pixel exact | An approximation |
| Typical formats | PNG, GIF | JPEG, WebP, AVIF |
| Size reduction | Modest | Much larger |
| Best for | Logos, text, screenshots | Photographs |
Lossless compression, perfectly reversible
Lossless compression stores the exact same pixels in fewer bytes and always hands them back unchanged. It "allows the original data to be perfectly reconstructed from the compressed data" with no loss of information (Wikipedia: lossless compression). Decode a PNG a thousand times and you get the identical picture every time. The tradeoff is reach: lossless can only squeeze out redundancy, so it never shrinks a photo as far as lossy does.
Lossy compression, smaller with data discarded
Lossy compression uses "inexact approximations and partial data discarding" to hit far smaller files, and "the amount of data reduction possible using lossy compression is much higher than using lossless techniques" (Wikipedia: lossy compression). It targets the detail your eye is least likely to miss, which is why a photo can lose most of its bytes and still look the same. The catch is that the discarded data is gone for good.
How does image compression actually work?
Image compression works by finding data it can drop or pack tighter, then re-encoding what is left. The two families reach that goal along completely different paths, so it helps to walk each one.
Lossy: transform, quantize, and encode
The dominant lossy method is transform coding, and JPEG runs it in a clear sequence. First the image is split into small blocks and each block passes through the discrete cosine transform, or DCT, which turns pixel values into frequency components and separates the smooth parts of a block from its fine detail. The DCT is the most widely used form of lossy compression. Second, quantization rounds off or drops the components that matter least to your eye, hitting fine detail hardest. Third, entropy coding packs whatever survives into as few bits as possible.
Most encoders add one step before all that: chroma subsampling, which stores color at lower resolution than brightness, because the eye reads brightness more sharply than color. Run the standard 4:2:0 scheme on that same 12 megapixel photo and the two color channels drop from 24 million samples combined to 6 million, a 75 percent cut in color data before the DCT even runs. Between subsampling, the DCT, and quantization, JPEG and similar formats reduce file sizes by 70 to 90 percent versus uncompressed data (Cloudinary: how JPEG compression works).
Lossless: model the patterns, shorten the codes
Lossless compression finds statistical redundancy, patterns that repeat, instead of throwing anything away. A lossless encoder builds a model of which patterns are common, then assigns short codes to common patterns and longer codes to rare ones. PNG uses DEFLATE, which pairs a pattern matcher called LZ77 with Huffman coding; GIF uses a related method called LZW over a palette capped at 256 colors.
One consequence is worth knowing. By the pigeonhole principle, no lossless compression algorithm can shrink the size of all possible data. A compressor that makes some files smaller must leave others the same or larger. That is why a lossless pass sometimes adds a few bytes to an already compressed file. It is math, not a bug.
Common image compression formats and what they use
The formats you meet every day each pick a different compression method and a different point on the size versus quality curve. Knowing which family a format belongs to tells you what to expect back from it.
| Format | Core method | Family |
|---|---|---|
| JPEG | DCT, chroma subsampling, entropy coding | Always lossy |
| PNG | DEFLATE (LZ77 plus Huffman) | Always lossless |
| GIF | LZW over a 256 color palette | Always lossless |
| WebP | Transform coding, or a lossless mode | Either |
| AVIF | AV1 style transform coding, or lossless | Either |
The tool on this site works with JPG, PNG, WebP, and AVIF, and can change the format on output. PNG stays lossless when you compress it; JPEG, WebP, and AVIF are lossy, with WebP typically 25 to 35 percent smaller than a JPEG of the same visual quality and AVIF often about half the size.
How much smaller does image compression make a file?
Image compression routinely cuts a photograph by 60 to 80 percent with nothing visible at normal size, and the total ratio measured from raw pixels is far larger than that. The clearest way to see it is to follow one real photo down the whole chain.
Start with the raw pixel data for a 12 megapixel photo: about 36 MB, as computed above. Your camera already saves it as a JPEG at roughly 4.5 MB, an 8 to 1 cut before you touch it. Drop that JPEG into the compressor on this page at the default quality 80 and it comes back near 0.9 MB, another 5 to 1. From raw pixels to the final file, that is about 40 to 1, and the last step is the one you can see and control.
| Stage | Size | Cut from previous |
|---|---|---|
| Raw pixel data | 36 MB | none |
| Camera JPEG | 4.5 MB | about 8 to 1 |
| Compressed at quality 80 | 0.9 MB | about 5 to 1 |
Those numbers hold up on smaller files too. The demo on the homepage takes a 497 KB JPG down to 214 KB as WebP at quality 80, which is 56.9 percent smaller with no visible change. The exact ratio depends on the photo and the setting, but the shape is always the same: a large cut you cannot see, and a further cut if you are willing to trade a little detail.
Image compression versus resizing, what is the difference?
Compression and resizing both make a file smaller, but they are not the same thing, and mixing them up leads to blurry images. Compression re-encodes the same pixels into fewer bytes. Resizing changes the pixel dimensions themselves, which is a separate lever with a separate cost.
| Action | What changes | What you lose |
|---|---|---|
| Compression | Bytes per pixel | Some fine detail (lossy) or nothing (lossless) |
| Resizing | Pixel width and height | Pixels, permanently, so it looks soft if enlarged later |
| Changing resolution | Dimensions or DPI tag | Detail if you scale down, sharpness if you scale up |
The practical rule: compress first, and only resize when the image is genuinely bigger in pixels than it will ever be displayed. A 6000 pixel wide photo shown in a 1200 pixel column can be resized down with no loss you would notice, then compressed on top. Doing it in that order gets the smallest honest file.
A short history of image compression
Image compression as we know it took shape across a few key inventions. Huffman coding, still inside PNG's DEFLATE today, dates to 1952. The discrete cosine transform arrived in the 1970s and became the engine of lossy compression. JPEG itself "was introduced by the Joint Photographic Experts Group in 1992" and grew into the most widely used image format in the world, with several billion JPEG images produced every day as of 2015 (Wikipedia: image compression).
The newer formats build on the same ideas with better math. WebP came out of Google in 2010, and AVIF, derived from the AV1 video codec, followed in 2019. Each squeezes more out of a photo than JPEG at the same quality, which is why the modern default has moved toward them.
When should you use lossy or lossless compression?
Use lossy compression for photographs and lossless compression for anything with hard edges, flat color, or transparency. That single rule covers most decisions you will ever make about an image file.
Photographs have smooth gradients and fine texture that lossy formats handle beautifully, so JPEG, WebP, or AVIF at a sensible quality give you a small file that looks identical. Logos, icons, screenshots, line art, and anything with text stay crisp only under lossless PNG, because lossy compression smears the sharp edges those images depend on. When you need transparency, PNG or WebP are the honest choices. And when a file is already compressed, running it through a lossy encoder again only costs quality, so keep the original whenever you can.
What can go wrong with image compression?
The main risks are re-compressing lossy files, picking the wrong format, and pushing quality too low. None of them are mysterious once you know the shape of each, and all three are avoidable.
Generation loss from re-saving
Every time you open a JPEG, edit it, and save again, the lossy encoder runs a fresh pass and discards a little more. Do that enough times and the image visibly degrades, an effect called generation loss. The fix is to keep an original in a lossless format and export a fresh JPEG each time, rather than editing the JPEG in place over and over.
The wrong format for the content
Saving a photograph as PNG produces a huge file, because lossless compression cannot exploit the smooth gradients a photo is made of. Saving a logo or a screenshot as JPEG blurs the sharp edges and adds a faint halo around text. Match the format to the content: photographs to lossy, graphics and text to lossless, and you avoid both traps.
Over-compression artifacts
Push a lossy setting too low and the damage becomes visible: blocky squares where the DCT blocks show through, and banding across what should be a smooth sky. Quality 80 is a safe default for photographs, and going far below it to chase a slightly smaller file is usually a false economy you can see.