2026-06-26 · Calc-Tools Editor

How to Compress Images Online: Complete Guide

Image compression comes down to one trade-off: getting the byte count as low as possible while the result still looks right on screen. Two things set that boundary — the pixel dimensions of the image and the high-frequency detail the encoder throws away. The first is usually decisive, and the second is usually overrated.

This guide starts with the encoding itself: what JPEG's DCT and quantization actually discard, and why PNG's DEFLATE compression is helpless on a photograph. From there it covers a five-format comparison, the non-linear relationship between the quality slider and file size, worked examples you can reproduce, and how image weight feeds into Largest Contentful Paint. Every file size quoted here is a typical value and varies with image content.

1. Lossy and Lossless: Two Different Routes

Every image compression scheme answers the same question: can the decoder guess what is missing? Lossless compression only exploits patterns already present in the data, so the decoded result matches the original pixel for pixel. Lossy compression deliberately discards information and spends image quality to buy a smaller file.

JPEG takes the lossy route. It converts RGB into YCbCr, separating brightness from two colour channels, then applies chroma subsampling because the human eye resolves brightness far better than colour — the colour channels can be stored at half or even a quarter of the resolution. Each channel is then split into 8x8 blocks and run through a discrete cosine transform (DCT), which converts pixel values into frequency coefficients. The top-left corner of a block holds the smooth, low-frequency content; the bottom-right holds fine detail and noise.

Then comes the one genuinely irreversible step: quantization. Each coefficient is divided by a step size taken from a quantization table and rounded to an integer. Larger steps push more high-frequency coefficients to zero, and runs of zeros cost almost nothing after run-length and Huffman coding. This is why the JPEG quality setting is really just a scaling factor on that quantization table: lowering quality widens the steps, and the drop in quality and the drop in file size are the same action. It is also why JPEG is never truly lossless — at quality 100 the chroma subsampling and the rounding are still there, merely hard to see.

PNG takes the lossless route. Each pixel row is filtered against a prediction built from neighbouring pixels, storing only the prediction error, and the result is compressed with DEFLATE — LZ77 dictionary matching combined with Huffman coding, which saves space by finding repeated byte sequences and referencing them. That works brilliantly on flat colour, clean lines and text edges, where repetition is everywhere. It fails on photographs, where every pixel differs slightly from its neighbour and there is almost nothing to reference. That single fact explains why the same photo stored as PNG is several times larger than a JPEG.

2. When Compression Becomes Mandatory

Compression is not a matter of taste; it is the entry ticket for several hard limits:

• Page speed: images are usually the heaviest resource on a page, so their weight sets the load time
• Search performance: page speed is a ranking signal, so image weight indirectly affects how pages are indexed and ranked
• Mobile data: visitors on metered connections pay for every byte, and smaller images cost them less
• Upload caps: many platforms reject a single image above a fixed size, and submission simply fails
• Email attachments: providers cap total attachment size, and a couple of unedited originals can push a message over the limit

These five situations do not want the same settings. Web images should be as light as possible, archived files should keep quality headroom, and email attachments sit in between. Deciding the purpose first removes most of the guesswork.

3. Five Formats Side by Side

A format decides which compression techniques are even available, not how well they are applied. The table below lines up compression type, transparency, animation and the typical use case:

Three details get overlooked. GIF's "lossless" label is relative to a 256-colour palette — if the source has more colours, the palette reduction is itself a lossy step. PNG transparency is a real alpha channel, so edges can be partly opaque, whereas GIF is either fully transparent or not at all; that is why rounded icons with soft shadows turn jagged when exported as GIF. And WebP and AVIF both ship lossy and lossless modes, so picking the wrong one can multiply the file size — lossless for a photo, or lossy for a flat icon, are the two classic mistakes.

On browser support, only the direction matters: JPEG, PNG and GIF always work, while WebP and AVIF are now widely supported in modern browsers but still fail in older browsers and in some desktop software. The safe pattern is to serve the modern format first and keep a JPEG or PNG fallback alongside it.

4. The Quality Slider Is Not Linear

Dragging quality from 100 down to 0 does not reduce the file at a steady rate. The quantization table explains why. At high quality the step sizes are tiny, so most high-frequency coefficients survive — they contribute little to what you see but cost a lot of bits. Widen the steps and those coefficients collapse to zero in whole blocks, producing a sudden drop in size. Widen them further and there is little left to zero out, so returns fall away sharply while visible damage starts to appear.

The table below re-exports one 4000x3000 photograph at different quality levels, normalised against quality 80 (typical values, actual results vary with image content):

The reading is blunt: going from quality 100 to 80 removes roughly two thirds of the file, while going from 80 to 60 removes less than a fifth more and introduces visible damage. So move quickly through the top of the range and settle somewhere between 70 and 85, rather than probing below 50. Past that point, blocking (squares in flat regions) and mosquito noise (fringing along sharp edges) become impossible to ignore.

5. Resize First, Compress Second

Size starts with the pixel count: halving each dimension cuts the pixel count to a quarter, and the compressed file typically shrinks in roughly the same proportion (typical value, actual results vary with image content). Dropping a 4000-pixel-wide photo into an 800-pixel-wide column wastes every extra pixel — they cannot make the on-screen image sharper, but they are fully paid for in download time.

So the order has to be resize, then compress. Doing it the other way round means resampling an already-lossy image and compressing it a second time: two generations of loss, no size benefit. What matters is not the original width but the width it will actually be displayed at. Body images usually sit in a container 800 to 1200 pixels wide; allowing for 2x pixel-density screens, exporting at 1600 to 2400 pixels is enough, and anything beyond that never reaches the viewer.

Two more decisions follow from dimensions. Cropping removes the parts of the frame nobody sees and saves more bytes than any quality setting. Matching the format to the content sends photos down the lossy path and icons and screenshots down the lossless one. Handle the geometry in resize and crop first, then run the result through the image compressor; if the source format is the wrong starting point, convert it first with the format converter. For more on balancing dimensions against quality, see best practices for image sizing.

6. Three Worked Examples

Example 1: a 4000x3000 phone photo. The original is about 5.2 MB. Re-exporting at quality 80 without touching the dimensions gives about 680 KB, roughly 13% of the original. Scaling the long edge to 1600x1200 — 16% of the original pixel count — and exporting at quality 80 brings it to about 180 KB. Together that is 5.2 MB down to 180 KB, or about 3.5% of the starting weight. One counter-intuitive detail: re-exporting that original at quality 100 will not bring back 5.2 MB. The high-frequency detail lost in the first lossy pass does not return; quality 100 only means "this pass discarded the least", not "restored".

Example 2: saving the same file repeatedly. Open a JPEG and save it five times at quality 80. The first export is about 680 KB and the size barely moves afterwards, yet the image keeps degrading: blocking deepens in flat areas and fringing spreads along sharp edges. This is generation loss. Compress once, keep the original archived, and never use an already-compressed file as the editing master.

Example 3: a 1200x800 interface screenshot. As PNG it is about 420 KB, because the text edges and any transparency have to stay exact. If no transparency is needed, quality 80 JPEG brings it to about 90 KB — but the high-contrast text edges pick up colour fringing, visible as red and blue speckles when zoomed, the signature artefact of chroma subsampling. When both a small file and clean text matter, lossless WebP is usually smaller than PNG (typical values, actual results vary with image content) and is the sturdier choice for this kind of image.

7. Image Weight and LCP

Largest Contentful Paint measures how long the biggest element in the viewport takes to render, and on most content pages that element is a hero image or a large product shot. Download time scales with byte count — taking a hero image from 1.2 MB down to 180 KB cuts its download time to roughly a seventh under the same network conditions. That ratio depends only on the size ratio, not on bandwidth, so "how small" converts directly into "how much faster".

Four habits connect compression to LCP:

• Do not lazy-load the hero image. Deferred loading makes the browser discover it later, which delays LCP by design; lazy loading belongs on images below the fold
• Serve the right width. Export several widths and let responsive images pick one, so a phone stops downloading a 2400-pixel file for a 400-pixel viewport
• Declare width and height, or the aspect ratio. The browser can then reserve space before the image arrives, preventing the page from jumping as it loads
• Fix format and dimensions before touching quality. A photo saved as PNG, or a full-resolution file in a narrow column, cannot be rescued by the quality slider

One connected cost is easy to miss: embedding images as Base64 in HTML or CSS inflates them by about a third, since Base64 spends four characters to carry three bytes, and it removes the file from independent caching. Reserve that for icons of a few kilobytes.

8. What to Check Before Trusting a Compression Tool

Where the work happens. Many online compressors upload your image to a server first, which means photos, design files and screenshots containing personal information leave your machine. Browser-local processing avoids the upload entirely: no transfer wait, and no copy of your material on someone else's disk.

Whether the controls are separate. A single "compress" button cannot serve every case, because a web image wants quality around 80 while an archive or print master wants 95 or higher. You need independent control over quality and dimensions, not one fixed preset that bundles them together.

How transparency is handled. At minimum the tool should read and write JPEG, PNG and WebP, and handle an alpha channel correctly. Converting a transparent PNG to JPEG has to fill the empty area with a sensible solid colour, and a careless conversion leaves black edges behind.

9. Frequently Asked Questions

Does compression always cost image quality?

No. With a lossless format such as PNG, or WebP in lossless mode, the decoded image matches the original pixel for pixel; the trade-off is a more modest size reduction. Lossy compression does discard high-frequency detail, but around quality 80 that loss usually sits below what a screen can display. The real danger is repeated saving, because every lossy pass adds another layer of damage.

How good is WebP support today?

Modern browsers widely support WebP, including lossy, lossless, partial transparency and animation. What still fails is older browsers and some desktop applications. The dependable pattern is to offer WebP first while keeping a JPEG or PNG fallback, so clients that cannot decode WebP take the fallback automatically.

Why is the same screenshot so much bigger as PNG than as JPEG?

Because the two mechanisms are complementary. PNG relies on DEFLATE finding repeated byte sequences, and a screenshot's flat colour and regular text edges repeat heavily — until the image contains a photo, a gradient or noise, at which point the repeats disappear and the PNG balloons. JPEG ignores repetition, discards high frequencies through quantization, and therefore excels on photos but fringes sharp text with colour artefacts.

Can a compressed image still be printed?

Yes. Compression changes encoding precision, not pixel dimensions — it is resizing that limits printing. At the conventional 300 dpi, 1600 pixels of width supports a print roughly 13 cm wide. For anything destined for print, archive a separate un-resized copy at quality 95 or above and use the compressed version only on the web.

How much smaller does the file get if quality is pushed to the minimum?

Returns fall off fast. On a typical photo, going from quality 80 down to 40 removes only around another third, and block artefacts and banding are already obvious. Halving the dimensions, by contrast, cuts the pixel count to a quarter for a far larger reduction in bytes while the only visible change is that the image is smaller. Shrink the dimensions before touching quality.

10. Three Common Misconceptions

Misconception 1: quality 100 means lossless. It does not. JPEG still applies chroma subsampling and rounds coefficients at quality 100; the quantization steps are simply small enough that the damage is hard to see. True losslessness requires PNG or WebP's lossless mode. The reverse also holds — saving a PNG as a quality 100 JPEG is not a lossless conversion, it is a conversion that introduces loss.

Misconception 2: only the quality slider matters. Quality gains have a ceiling, while dimension gains track the pixel count almost directly. A 4000-pixel-wide photo does not need all of its pixels for a body column or an email attachment. Shrinking to the real display width first usually saves more than any amount of fiddling with quality afterwards.

Misconception 3: convert everything to one format. Photos and icons want opposite things. Photos tolerate detail loss in exchange for aggressive high-frequency compression; icons and screenshots need every pixel exact yet repeat heavily. Converting a whole asset set to JPEG destroys icon edges and transparency, while converting it all to PNG inflates every photograph. Pick the format per content type.

11. Practical Checklist

• Set parameters by purpose. Web images: lossy format, quality around 80, width no more than twice the display width. Social sharing: JPEG at 80 to 90. Anything for print or further editing: keep an un-resized original at quality 95 or above
• Convert once, from the original. Archive the master and treat every export as a single pass from master to deliverable, so nothing is re-encoded on top of a previous result
• Never send transparency to JPEG. Keep alpha-channel assets as PNG, or as WebP with an alpha channel, or the transparent area gets filled with a solid colour
• Keep batch settings identical. Applying the same width and quality to a whole set keeps the page consistent and makes it easy to trace which image is slowing things down
• Judge at the real size. Compare compressed and original side by side at the size they will actually be displayed, not zoomed to 100% hunting for differences

Put those three decisions in order — format by content type, dimensions by display width, quality somewhere between 70 and 85 — and image handling stops being guesswork. For batches, start with the image compressor; for the finer points of picking a format, continue with the format conversion guide.