How to reduce a photo's file size without visible quality loss

Three things decide how much a photo weighs

The site says the file is too large. Before you reach for any slider, know that a photo's weight comes from three choices, and each one charges a different price.

• Pixel dimensions. How many pixels the image has. Halve the width and the height and only a quarter of the pixels are left to store.
• Quality (compression level). How much detail the encoder throws away inside each block of the image.
• Format. JPG and WebP discard what the eye barely notices; PNG keeps every pixel.

The order that usually works: crop, fit the dimensions to the use, and only then pick quality and format.

Why a phone photo weighs megabytes

A 12-megapixel photo is 4,000 × 3,000 pixels: 12 million of them. Each one stores red, green and blue at one byte apiece, so uncompressed it would take 36 MB. The JPEG your camera saves is already a compressed version of that.

Manufacturer figures give the scale. Canon lists about 3,084 KB per 12 MP photo at the Fine setting of two of its cameras and 1,474 KB at Normal, noting that the figure changes with the subject. Apple says a 12 MP ProRAW file is about 25 MB and 10 to 12 times larger than a HEIF or JPEG, which works out to 2 to 2.5 MB for an everyday shot.

In other words, the file already reaches you 10 to 25 times smaller than its raw pixels. To shrink it further, you either remove pixels or accept heavier compression.

A JPEG quality number is not a percentage

Quality 80 does not mean 80% of the photo survived. In libjpeg-turbo, a reference implementation of the JPEG standard, the number only scales the quantization table: the divisors that round off the data in each 8 × 8 block of pixels. At 50 the standard's sample table is used as is; at 75 the divisors are halved; at 90 they drop to one fifth; at 100 every one of them becomes 1.

That is why 100 is wasteful. The libjpeg documentation warns that above about 95 the file grows dramatically for a gain you can measure but rarely see, and that even 100 still loses information to rounding and chroma subsampling. For photographs it points to the 50–95 range, with 75 as the default; Google's classic Lighthouse audit used 85 as its yardstick.

In the LivreImage compressor the slider runs from 30 to 100 and opens at 82. The value goes to your browser's own encoder, so the same number can produce different files from one browser to the next. Judge with the Compare button, not the number.

Chroma subsampling in one paragraph

Eyes pick up changes in brightness far better than changes in color. JPEG exploits that by storing color at a lower resolution: in the 4:2:0 scheme, libjpeg's default, a single color value serves each 2 × 2 square of pixels. In photographs almost nobody notices; the damage shows on colored text over a flat background, which picks up a fringe. Lossy WebP always uses 4:2:0; for JPG on LivreImage, the browser decides.

Why PNG is huge for photographs

PNG is lossless: it describes each pixel by how it differs from its neighbors and hands every one back exactly. That pays off in screenshots, logos and charts. A photograph is texture and noise from edge to edge, so there is little to save without discarding something. web.dev's image course is blunt about it: PNG is almost never the right choice for photographic content.

On LivreImage, picking PNG locks the quality slider, because the format has no such setting. To make a PNG photo genuinely smaller, switch the output to JPG or WebP. In Google's own study, lossy WebP came out 25% to 34% smaller than JPEG at the same quality as measured by the SSIM index.

Resize or compress: which comes first

Dimensions first. web.dev's guidance is to serve an image at the size it is displayed: a 500-pixel slot calls for 500 pixels, or 1,000 on a 2x screen. A photo 4,000 pixels wide sitting in an 800-pixel column carries 25 times the pixels a standard screen shows there. On Resize image, Max width only shrinks: an image narrower than the value is left alone.

Compression comes second, and there is no universal number; web.dev itself says to try levels until looks and weight balance. Start from the suggestions below and check the result in Compare.

Only the limits quoted in the Note column come from official sources; the widths and quality values are our recommendations.

How to hit an exact KB limit

A form does not negotiate: 100 KB means 100 KB, and getting there by hand is trial and error. LivreImage's target pages, from 20 KB to 1 MB, run the search for you in three stages.

1. Quality, at the original size. The page looks for the highest quality between 50 and 96 that fits the limit, in a binary search. If even 50 does not fit, it goes no lower: it starts removing pixels.
2. Downscaling. Width and height shrink 15% per step, for up to 16 steps, and the 50-to-96 search runs again at each size. The first size where a quality fits wins.
3. Last resort. At the smallest size, any quality between 5 and 50 that fits is accepted. If a stage fit, the card shows a “target met” tag. If none did, the page delivers the smallest file it reached and labels it “smallest possible”.

Two details that prevent a rejection

PNG has no quality to search, so only the downscaling steps apply. In a test of ours in September 2026, a 12-megapixel photo reached 100 KB at 1282 × 962. And the 100 KB target is 102,400 bytes (1 KB = 1,024 bytes); a system that counts 1 KB as 1,000 bytes will refuse a 101,000-byte file that meets the target here.

Recompressing a JPG compounds the loss

Every time a JPG is opened and saved again, the image goes through another round of rounding. The libjpeg documentation says to avoid repeated compression and decompression cycles: the loss accumulates, and after ten or so cycles the image may be noticeably worse than after one. Amazon gives its sellers the same instruction: avoid saving multiple times in JPEG while editing, because each save reduces image quality.

LivreImage always decodes the image and encodes it again; it does not losslessly optimize a JPG that already exists. In practice:

• Start from the camera original, not from a copy another program has already shrunk.
• Do the crop, the resize and the compression in a single pass.
• Keep the original: every future version should come from it.

What metadata adds to the file

Besides pixels, a photo carries blocks of information: the Exif data written by the camera, an embedded thumbnail, the color profile and, if location was on for the camera, the coordinates of the place. How much that weighs varies from file to file; the libjpeg documentation notes that in some files these extra blocks can be sizable.

LivreImage rewrites the pixels only: every file it generates comes out without Exif, and the card shows an “EXIF stripped” tag. That trims weight and keeps the location from traveling with the photo. In exchange, nothing the camera recorded reaches the smaller copy — one more reason to keep the original.