How to Reduce Image File Size Without Visible Quality Loss

The three levers, in order

1. Dimensions. How many pixels the image contains. Halving both width and height removes three quarters of the pixels, and file size follows closely.
2. Format. How those pixels are encoded. Getting this wrong — a photograph stored as PNG, a logo stored as JPG — can cost several times the necessary bytes.
3. Quality setting. How much detail a lossy encoder discards. Useful, but the smallest of the three levers and the only one that can actually hurt how the image looks.

The order matters because the levers multiply. A 4000×3000 photo saved as PNG might be 12MB. Resizing it to 1200×900 cuts it to roughly a tenth. Switching to JPG cuts that by another large factor. Only then does dropping quality from 95 to 82 do its work, and by that point it is shaving a small remainder rather than papering over a problem that resizing should have solved.

Do it in the opposite order and you get the worst outcome: an image crushed to quality 40 to hit a size target, still carrying four times the pixels it needs, visibly artifacted and larger than it should be. If an image looks bad after compression, the usual cause is that step one was skipped.

Lever 1: resize before you compress

Pick target dimensions from where the image is actually displayed, not from what the camera produced.

Two multipliers to keep in mind. High-density displays mean you want roughly twice the CSS pixel width for a sharp result — an image displayed 600px wide should be about 1200px in the file. And beyond 2x the returns collapse: 3x is nearly indistinguishable from 2x while carrying more than double the bytes.

Lever 2: match the format to the content

A short version of the decision, covered at length in our format comparison guide:

• Photographs → lossy WebP, or JPG where compatibility matters. A photograph stored as PNG is the single most common and most expensive format mistake, often costing five to ten times the necessary size.
• Flat graphics, logos, screenshots, pixel art → PNG, ideally palette PNG. JPG on flat art produces visible ringing around every edge and a larger file than PNG. Lossy WebP is also frequently larger than a palette PNG here.
• Anything needing transparency → PNG, or lossy WebP if the content is photographic. JPG has no alpha channel and will fill your transparency with a solid color.

One real example: a 606KB PNG social card re-exported as JPG at quality 82 came out at 81KB, an 87% reduction from changing one dropdown. It was a photographic image stored in a format built for flat graphics. In the other direction, converting soft gradient page backgrounds from PNG to WebP dropped them by roughly 57% — smooth content with no hard edges is exactly what lossy coding handles best.

Lever 3: the quality setting, and where it stops helping

For JPG and lossy WebP, quality is a number from 0 to 100 that controls how aggressively the encoder quantizes. The relationship between that number and file size is strongly non-linear, and knowing the shape of the curve tells you where to sit.

Going from 100 to 90 often removes half the file with nothing perceptible lost. Going from 90 to 80 removes a good chunk more, still invisibly on photographic content. Going from 80 to 70 saves noticeably less while starting to show. Below 60, each further step costs visible quality for shrinking returns. That is the diminishing-returns curve, and it is why quality 80 is such a common default: it sits right at the knee.

Content shifts the knee. Busy, detailed photographs hide artifacts well and tolerate 70. Images with large smooth areas — skies, studio backdrops, gradients — show banding earlier and want 85. Anything containing text or sharp edges should not be in a lossy format at all.

When PNG needs palette quantization

PNG has no quality slider, but it does have a lever most people never touch: reducing the color count. A truecolor PNG stores four bytes per pixel; a palette PNG stores a one-byte index into a table of up to 256 colors. For images that genuinely use few colors, the palette version is several times smaller and, if every color in the image fits in the table, mathematically identical.

Good candidates:

• Logos, icons, and flat illustrations with a handful of colors.
• Pixel art, which is usually authored to a restricted palette anyway.
• UI screenshots, which are mostly flat regions and text.
• Charts and diagrams.

Poor candidates: photographs, anything with smooth gradients, and images with soft anti-aliased edges against many different backgrounds. Quantizing those introduces banding, and a good quantizer will dither to hide it — which adds noise, which compresses badly, which partly undoes the saving.

Alpha needs care here. Palette PNG supports per-palette-entry transparency, so a partially transparent anti-aliased edge consumes palette slots for each blend level. An icon with a soft shadow can burn a large fraction of the 256 entries on shadow gradations. Check the result against a contrasting background before shipping.

Strip the metadata

Camera and phone images carry EXIF blocks: exposure settings, lens model, timestamps, thumbnails, and often GPS coordinates. Design tools add their own chunks. This is typically tens of kilobytes and occasionally far more when an embedded color profile or preview thumbnail is present.

On a 2MB photo it is noise. On a 40KB thumbnail, 15KB of EXIF is more than a third of the file. And there is a second reason beyond size: GPS coordinates in a photo you publish tell everyone where it was taken, which is a privacy problem people rediscover the hard way.

Two things worth keeping deliberately: the color profile, if the image is not already in sRGB (stripping it makes colors shift), and copyright fields if you rely on them. Note that any browser-based tool that re-encodes through a canvas strips metadata automatically as a side effect, since the canvas holds pixels and nothing else.

Recipes for common targets

Under a 25MB email attachment limit

Usually a batch of phone photos. Resize each to 2000px on the long edge, export JPG at quality 85. A typical 12-megapixel photo lands around 500KB, so forty of them fit. If you need more, drop to 1600px before dropping quality — the recipient is viewing on a screen, not printing a poster.

Under a 100KB form or upload cap

Common for profile photos, document uploads, and job applications. Work top-down: resize to the maximum displayed size (often 800px or less), export JPG at quality 80, and check. If still over, step to 70, then reduce dimensions further. Resist going below quality 60 — a 600px image at quality 75 looks considerably better than an 1200px image at quality 45, at the same file size.

Web page images

Aim for under 200KB per content image and under 500KB for a hero. Serve multiple sizes via srcset so phones do not download the desktop version. Lazy-load anything below the fold. And check what the page actually requests — a common failure is a CMS serving the 4000px original with a CSS width of 600px, where the entire problem is a template setting rather than the image file.

Game texture budgets

Different rules apply, because what matters is GPU memory, not download size. GPU memory is driven by dimensions and texture format, not by the PNG's compressed size on disk — a heavily optimized PNG and a bloated one occupy identical VRAM once uploaded. Keep source art lossless, size textures to powers of two where your pipeline wants them, and let the engine's import settings handle GPU compression. Optimizing the PNG itself only affects install size.

Frequently asked questions