Does compressing an image lose quality?

A JPEG or a palette-reduced PNG loses something every time, and it is gone for good. A lossless PNG pass loses nothing at all — it rewrites the same pixels with better filtering. Which of those you get is stated on the control before you press the button, and the comparison at 400 percent is there so you can decide whether the loss matters on your picture rather than on a general claim.

Why is my photo still five megabytes after compressing it?

Usually because it was already close to its quantisation floor, and a second pass over an efficient JPEG spends detail without buying bytes. The ledger says so in that case rather than showing a one percent improvement as a success. The other common cause is pixel count: a 48 megapixel phone photograph is large because it has 48 million pixels, and quality alone will not fix that.

Will the width and height of my picture change?

No. Every mode here keeps the pixel dimensions exactly as they were. There is one exception and it is never automatic: if a byte cap cannot be met at the format's floor, the tool reports that and offers a reduction of the long edge as a separate step, with both dimensions shown before you agree to it.

Can I hit exactly twenty kilobytes?

The search finds the largest file that fits under the cap, not a file of exactly that size, because the encoder's size is a step function of quality rather than a dial. In practice a 20 KB cap yields something in the high teens. That is what an upload form checks: at most 20 KB, not exactly 20 KB.

Is the file sent anywhere?

There is nothing to send it to. This site is a static export with no server and no API route, so no endpoint exists that could accept a file. The bytes are read by this page, decoded to pixels, re-encoded in a worker and handed to your download folder, and they are gone when the tab closes.

Why did my PNG come back larger than it went in?

Because it was already optimised, and a re-encode of an optimised PNG has nothing left to find. The ledger marks that row as no gain, leaves it out of the download and tells you to keep the file you have. A PNG that grew is a result worth reporting, not one worth hiding.

Compress Image — fewer bytes, same pixel dimensions

What compression takes away

A JPEG is stored as blocks of eight pixels by eight, each turned into a set of frequency coefficients, each coefficient divided by a number from a quantisation table and rounded. The quality setting chooses that table. Rounding is where the bytes go, and what it rounds away is the fine end of the picture: the edge of small text, single-pixel highlights, film grain, the texture of skin. None of it comes back on the way out.

A PNG works the other way round. Nothing is discarded unless you ask for it: the lossless pass encodes the picture under more than one row filter, keeps whichever attempt came out shortest, and hands back pixels that are bit-for-bit the pixels that went in. Ask for a palette instead and every pixel is remapped to the nearest of the colours you allowed, which is why a screenshot survives it and a sunset does not.

Neither mechanism changes how big the picture is. A 4032 by 3024 photograph that leaves here at 180 KB is still 4032 by 3024 — though read that figure for what it is: twelve million pixels carrying about one byte for every sixty-six of them, which is a hard squeeze and a visible one, not a free result you should expect on every file. Dimensions surviving is the whole promise of this page, and it is the reason the one operation that would change them — reducing the long edge when a cap is out of reach — is a question rather than a step.

This tool cannot keep your metadata.

The re-encode rebuilds the file from pixels, so EXIF, GPS, the maker notes, the embedded thumbnail, IPTC, XMP and the ICC profile all go, together, every time. The ledger lists each block and what it weighed so you can see what the saving was made of. If you need the capture date or the copyright field to survive, this is the wrong tool and no setting here will change that.

The JPEG encoder here is the browser's own.

There is no MozJPEG-class codec in this build, which means no trellis quantisation, no choice of chroma subsampling and no progressive scan script. A dedicated desktop encoder will beat what you get here by roughly ten to twenty percent at the same visual quality. What you gain instead is that nothing is uploaded and nothing is installed.

The pass, step by step

1The file is read from disk by this page. Its first megabyte is walked segment by segment for metadata blocks, and each block's length is added up — that is where the itemised figures in the ledger come from.
2Orientation is resolved once. The browser is tested with a two-pixel JPEG that carries a rotation flag, and the rotation is applied by hand only if the browser did not already apply it, so a phone photograph never comes out sideways or twice-rotated.
3You choose the mechanism: a quality, a byte cap, or a percentage off. Nothing is encoded until you do.
4The encode runs in a worker. For a byte cap, the first trial is the format's floor — if even that overshoots, you know after one encode instead of eight — and the remaining trials climb back up looking for the best setting that still fits. Every trial is printed with its size as it lands.
5The result is decoded again for the comparison. What you magnify to 400 percent is the file itself, not a preview of it, so the bytes you approve are the bytes you save.
6One file downloads on its own. Several download as a stored ZIP, and any row that came back no smaller than its original is left out with a line saying why.

Formats, and where each one stops

A JPEG leaves as a JPEG and a PNG leaves as a PNG. The extension never changes on its own for either of them.

JPG and PNG are read and written. These are the two formats this build encodes, and the two the routes below go into properly.
WebP, AVIF, GIF, BMP, TIFF and HEIC are read but not written. A file in one of those leaves as PNG if it has transparency to keep and as JPG if it does not, and the row says so before you press anything. An efficient WebP re-encoded as JPG can easily come back larger; that is reported rather than hidden.
Animated GIF and animated WebP lose their animation here — the first frame is what gets decoded. If the animation matters, do not use this page.
A CMYK JPEG is converted to sRGB by the browser's own decoder before this tool sees a pixel, and a 16-bit PNG drops to 8 bits per channel on the way through.
Intake stops at 120 MB a file and 100 files a session. Above roughly 32 megapixels — 16 on iOS — you are offered a lighter working copy as a question, because past that a canvas fails by handing back a blank image rather than by reporting an error.

Asked often

Does compressing an image lose quality?: A JPEG or a palette-reduced PNG loses something every time, and it is gone for good. A lossless PNG pass loses nothing at all — it rewrites the same pixels with better filtering. Which of those you get is stated on the control before you press the button, and the comparison at 400 percent is there so you can decide whether the loss matters on your picture rather than on a general claim.
Why is my photo still five megabytes after compressing it?: Usually because it was already close to its quantisation floor, and a second pass over an efficient JPEG spends detail without buying bytes. The ledger says so in that case rather than showing a one percent improvement as a success. The other common cause is pixel count: a 48 megapixel phone photograph is large because it has 48 million pixels, and quality alone will not fix that.
Will the width and height of my picture change?: No. Every mode here keeps the pixel dimensions exactly as they were. There is one exception and it is never automatic: if a byte cap cannot be met at the format's floor, the tool reports that and offers a reduction of the long edge as a separate step, with both dimensions shown before you agree to it.
Can I hit exactly twenty kilobytes?: The search finds the largest file that fits under the cap, not a file of exactly that size, because the encoder's size is a step function of quality rather than a dial. In practice a 20 KB cap yields something in the high teens. That is what an upload form checks: at most 20 KB, not exactly 20 KB.
Is the file sent anywhere?: There is nothing to send it to. This site is a static export with no server and no API route, so no endpoint exists that could accept a file. The bytes are read by this page, decoded to pixels, re-encoded in a worker and handed to your download folder, and they are gone when the tab closes.
Why did my PNG come back larger than it went in?: Because it was already optimised, and a re-encode of an optimised PNG has nothing left to find. The ledger marks that row as no gain, leaves it out of the download and tells you to keep the file you have. A PNG that grew is a result worth reporting, not one worth hiding.

When the format is doing the work

A file is sometimes large because it is in the wrong container rather than because it was written generously. A photograph saved as a PNG carries every pixel exactly, artefacts included, and commonly weighs eight times what the same picture weighs as a JPEG at a quality nobody could fault. A screenshot of black text saved as a JPEG is the same mistake pointing the other way: the letters get soft edges and the file is bigger than a palette PNG of it would have been.

Changing the container is a different job from making the container smaller, and this page does not take it on as a goal — a PNG that arrives here leaves as a PNG, whatever that costs. Where the change of format is the job, phototojpg.com is built for exactly that, and doing it there first usually makes the compression step here trivial or unnecessary.

The three mechanisms, one page each

Compress to a size in KBThe byte cap as the whole interface, with the caps that recruitment and university forms keep asking for.
Compress a JPEGWhat the quality number selects, and where the floor of an already-compressed JPEG is.
Compress a PNGThe lossless pass and the palette pass, kept apart, because only one of them is lossless.

Two things worth reading before a big batch

The controls above will let you run a hundred files without explaining why sixty of them barely moved. Two pieces of writing cover the cases where that happens, both short, both about files rather than about theory. The index of the guides says which is which and how long each takes.

Why this JPEG will not get smallerQuantisation floors, what a second re-encode costs, and when the honest answer is to leave the file alone.
Upload limits on Indian exam portalsWhat the photograph, signature and document fields measure, and the order to do the work in when a form caps both dimensions and bytes.