Why Your Image Is Still Too Large After Compressing

Each of these is expanded below, in the order you should check them.

Symptom: quality set to 40%, file dropped by 3%.

Quality settings apply to lossy compression, and PNG has none. Browsers ignore the quality argument entirely when encoding PNG, so dragging the slider does precisely nothing to a PNG that comes out as a PNG — the only levers left are fewer pixels or fewer colours.

This catches almost everyone with screenshots, because screen-capture tools default to PNG and screenshots are exactly the content people most often need to shrink for a bug report or a document.

Fix: change the output format. For a screenshot, WebP lossless keeps every pixel and is around 26% smaller than PNG by Google's measurement. For a photograph that was wrongly saved as PNG, WebP lossy or JPEG will cut it by an order of magnitude. The compressor detects this case — a PNG in the queue with PNG or "keep original" as the output — and offers a one-click switch to WebP rather than letting you discover the problem yourself.

Symptom: 80% quality, still 1.8 MB.

Compression re-encodes the same pixel grid more economically. Resizing removes pixels. They are separate operations, and the second is far more powerful because the effect is quadratic: halving both dimensions quarters the pixel count before any compression happens.

A 4000 × 3000 photograph has twelve million pixels. Even efficiently encoded, that is a large file — and if it is destined for an 800-pixel-wide column, over 90% of those pixels cannot be displayed at all.

Fix: set a longest-edge limit. The compressor's default is "Don't resize", so this is opt-in and easy to miss. Choose 1920px for a full-width web image, 1280px for most content, 1080px for social, 800px for a thumbnail. Most files that resist compression fall into place immediately, because the encoder finally has a sensible number of pixels to work with. Working out which number you need takes a minute in developer tools.

Symptom: the row says "Already optimised", or the output is larger than the input.

Compressing an already-compressed image usually makes it bigger. The first encoder's artifacts are themselves fine detail, and the second encoder dutifully spends bytes preserving them — so you pay for the damage rather than removing it.

Files that arrive in this state: anything downloaded from a website, images exported by a CMS, photographs that have been through a messaging app, and stock images. All have been compressed at least once.

The compressor has a safeguard on by default for precisely this. When the output would be larger than the input it keeps your original bytes and marks the file "Already optimised" instead of handing back a worse, bigger copy. That is the tool working, not failing.

Fix: accept that this file is close to its floor, and get the saving elsewhere — resize it, or convert the format, both of which change the arithmetic rather than re-treading it. If you genuinely need it smaller and it is already optimised at the right dimensions, the only remaining lever is visible quality loss.

Symptom: target-size mode ran and the result is still over the limit, or it is under the limit and looks terrible.

Target-size mode steps quality down repeatedly — up to twelve attempts — until the file fits. But quality is the only lever it pulls, so if the pixel count is too high for the target, it either cannot get there or gets there by destroying the picture.

Asking a 4000-pixel-wide photograph to fit in 50 KB is asking for about 3 bytes per thousand pixels. There is no encoder that makes that look acceptable.

Fix: give it fewer pixels and the same target becomes easy. Set the longest edge first, then the KB ceiling. A useful pairing: under 100 KB wants 1080px or below; under 500 KB is comfortable at 1920px.

Symptom: the tool warns you, and the output is a still image.

Canvas-based compression decodes and re-encodes a single frame, so an animation comes out as one picture. The compressor flags animated GIFs in the queue rather than silently flattening them, which is the honest behaviour but not a solution.

Animated GIFs are also enormous by nature: every frame is a full image with a palette of at most 256 colours, so a three-second clip can run to several megabytes.

Fix: convert the animation to a video format — an MP4 or a WebM of the same clip is routinely a tenth the size and looks better — or to animated WebP if it must stay an image. Neither is something a canvas-based browser tool can do, so this one needs different software; the honest recommendation is ffmpeg or a dedicated converter.

Symptom: the file is 1.9 MB, the limit says 2 MB, and it is rejected anyway.

Several things can be true at once here.

Base64 inflation. Some systems encode an attachment as Base64 before checking or storing it, which adds roughly a third to the size. A 1.9 MB file becomes about 2.5 MB and fails a 2 MB check that appeared to have room.

Megabytes counted differently. A "2 MB" limit may mean 2,000,000 bytes or 2,097,152. Your file manager and the server may disagree about whether your file is under it.

The limit is on the whole request. Other form fields, other files and multipart overhead all count. Two 1 MB images do not fit a 2 MB request limit.

A separate dimension limit. Some platforms cap pixel dimensions as well as bytes and report both failures with one unhelpful message.

Fix: aim about 25% under any stated limit and the class of problem disappears. If a form rejects a file without saying why, halve it and try again — that distinguishes a byte limit from a dimension limit in one step.

Sixty seconds, in this order:

1. What format is it, and what format is coming out? PNG in, PNG out, is the answer most of the time.
2. What are the pixel dimensions? Over 2000px on the long edge for something displayed at 800px is your answer.
3. Where did the file come from? Downloaded or already exported means already optimised, and the saving has to come from dimensions or format.
4. Is it animated? Then it is a video problem, not an image one.
5. What exactly is the limit measuring? Aim a quarter under it.

Notice that only one of those five is about compression settings. That is the real lesson of this article: a file that resists compression is nearly always telling you it needs a different operation — a resize, a format change, or a different destination — rather than a harder squeeze. The main how-to sets out the order that avoids the problem in the first place.