Is JPEG quality 100 lossless?

No, and it is not even close to being worth what it costs. JPEG throws information away at every setting it has, because the discarding happens in the frequency transform before the quality number is ever applied. Quality 100 only means the quantisation step is as gentle as the format allows. What it buys, measured below, is a similarity score 0.0007 higher than quality 95 in exchange for a file 2.8 times larger. On the stock photograph it was 2.5 times larger and on the already-compressed file 3.0 times. If you genuinely need lossless, the format is PNG or WebP in its lossless mode, and no JPEG setting will get you there.

Why did my file get bigger when I saved it as a JPEG?

Almost always because you asked for a higher quality than the file was originally saved at. A JPEG that arrived at quality 80 and gets re-saved at 95 has to spend bytes recording the compression artefacts of the first pass as if they were picture detail, and there are a lot of them. The measured case below is a photo downloaded from a social feed at 338 KB: saved at quality 85 it came back 371 KB, at 90 it was 409 KB, and at 100 it was 1.43 MB. It only broke even around quality 80. If a tool made your file bigger without telling you, that is what happened, and the right response is to keep the original.

Should I use JPEG for screenshots and text?

Usually not, though the reason is not the one people give. The file size argument does not hold: the screenshot measured below went from a 1.61 MB PNG to 427 KB at quality 90, which is a large saving. The problem is what JPEG does to hard edges. It rings, so every letter picks up a faint halo and every panel border gets a shimmer beside it, and unlike a photograph there is no texture to hide it in. At a glance the file looks fine; at 100% the text looks slightly dirty. PNG for anything with text in it, and WebP if the PNG is too heavy, since WebP does lossless and is typically 20% to 30% smaller.

Does the quality number mean the same thing in every program?

No, and this catches people out constantly. The JPEG standard defines quantisation tables, not a 0-to-100 scale, so every encoder invents its own mapping onto those tables. Photoshop's 0-to-12 slider, GIMP's 0-to-100, mozjpeg's 0-to-100 and the one built into your browser all produce different files at the same nominal number. Photoshop quality 10 is roughly quality 90 elsewhere, not 10. The only number that transfers between tools is the file size, which is why the tool this guide sits beside reports bytes and a measured similarity score instead of asking you to trust the setting.

What quality does a phone camera save at?

Between about 90 and 95 for most phones, and you can infer it rather than guess. Re-encode the file at a series of qualities and watch where the output size crosses the input size: that crossing is roughly where it was saved. The 4032 × 3024 phone photo measured below is 1.87 MB, and re-encoding it produced 1.99 MB at quality 95 and 1.51 MB at quality 90, so the original sits just under 95. This is also why "compress my phone photo losslessly" disappoints people. There is far less slack in the file than they expect, because the phone already took it.

Is WebP or AVIF better than a well-set JPEG?

Yes, by roughly 25% to 30% for WebP and more for AVIF at the same visual quality, and that gap is real rather than marketing. The catch is what can write them. Every current browser displays WebP; Safari still cannot encode one from a canvas, and no browser can encode AVIF at all, which is measured and dated on our image converter page. So a browser-based tool can offer you WebP on Chrome and not on Safari, and cannot offer AVIF anywhere. For a photograph going on a web page WebP is the better answer when you can get it. For a photograph going to a client, a printer or a phone gallery, JPEG is still the one that opens everywhere.

What JPEG quality setting should you use?

Quality 85 for most things, 90 if it matters, and never 100. Here is what each step actually costs, measured on five kinds of picture.

Free toolImage CompressorWatch the file get smaller and the picture stay the same, side by side, before you save anything.Open the compressor

The short answer

Use 85. On a photograph it gives you about half the file size of quality 95 for a difference you cannot find at 100% zoom. Move up to 90 when the picture will be looked at closely or edited again later. Drop to 75 when the file size matters more than the last of the detail, which on a web page it usually does.

Never use 100. It is the setting that feels safest and it is the one that wastes the most. On the phone photo below it produced a file 2.8 times larger than quality 95 in exchange for a similarity score 0.0007 higher. That is not a small win for a large cost. It is no win at all, for a very large cost.

Everything after this is the working, because a recommendation with no numbers under it is just another opinion, and the pages that rank for this question are full of those.

What I measured, and how

Five files, chosen to span what people actually compress: a phone photo, a large stock photograph, a phone screenshot, a piece of flat artwork and a JPEG that had already been compressed once by somebody else. Each was encoded at eleven quality settings from 100 down to 40.

Every result was decoded again and compared against the original at native resolution. That part matters more than it sounds. JPEG damage lives in the high frequencies, so comparing scaled-down copies throws away exactly the detail being measured and reports 0.999 for a file that is visibly wrecked. That was the first version of this harness and it was useless.

The score is SSIM on the luma channel in 8×8 windows, where 1.0000 is identical. It is not computed over the whole frame either, because a photograph is mostly sky, skin and wall and none of that suffers at any setting. The harness builds a coarse map of local detail, cuts six 192-pixel tiles from the busiest places, scores each, and reports the mean of the worst half. So these numbers are pessimistic on purpose: they describe the part of the picture that breaks first.

Chrome 151 on macOS 26.6.2, Apple M1 Max, 23 August 2026. Encoder is canvas.toBlob('image/jpeg', q), which is the browser's own. Byte counts are exact. Timings were deliberately not recorded: canvas work finishes asynchronously on a GPU-backed surface, so a stopwatch around the call measures the call rather than the work.

The sweep

Read down the "vs 95" column first. It is the file size as a multiple of what quality 95 produced, and it is where the argument lives.

Phone photo

4032 × 3024 JPEG, 1,956,848 bytes, straight off the camera roll

Quality	File size	vs 95	Similarity
100	5.34 MB	2.82×	0.9991
95	1.90 MB	1.00×	0.9984
92	1.55 MB	0.82×	0.9962
90	1.44 MB	0.76×	0.9946
85	1.02 MB	0.54×	0.9902
80	846.1 KB	0.44×	0.9873
75	713.5 KB	0.37×	0.9839
70	626.4 KB	0.32×	0.9813
60	495.5 KB	0.26×	0.9753
50	419.0 KB	0.22×	0.9704
40	349.6 KB	0.18×	0.9637

Stock photograph

5926 × 3951 JPEG, 2,483,248 bytes, fine detail across the whole frame

Quality	File size	vs 95	Similarity
100	8.09 MB	2.50×	0.9990
95	3.24 MB	1.00×	0.9982
92	2.65 MB	0.82×	0.9958
90	2.52 MB	0.78×	0.9974
85	2.17 MB	0.67×	0.9918
80	1.75 MB	0.54×	0.9770
75	1.06 MB	0.33×	0.9649
70	914.1 KB	0.28×	0.9631
60	784.8 KB	0.24×	0.9558
50	557.8 KB	0.17×	0.9470
40	453.9 KB	0.14×	0.9393

Phone screenshot

1179 × 2556 PNG, 1,612,761 bytes, flat panels and small text

Quality	File size	vs 95	Similarity
100	1.28 MB	2.37×	0.9978
95	554.8 KB	1.00×	0.9944
92	449.9 KB	0.81×	0.9917
90	416.9 KB	0.75×	0.9903
85	346.6 KB	0.62×	0.9862
80	304.8 KB	0.55×	0.9820
75	273.2 KB	0.49×	0.9773
70	253.1 KB	0.46×	0.9735
60	221.2 KB	0.40×	0.9647
50	198.8 KB	0.36×	0.9601
40	177.9 KB	0.32×	0.9429

Flat artwork

710 × 800 PNG, 652,284 bytes, a logo with hard edges and solid fills

Quality	File size	vs 95	Similarity
100	364.7 KB	2.61×	0.9284
95	139.8 KB	1.00×	0.9269
92	115.2 KB	0.82×	0.9258
90	106.9 KB	0.76×	0.9250
85	90.3 KB	0.65×	0.9226
80	80.0 KB	0.57×	0.9212
75	72.4 KB	0.52×	0.9197
70	67.2 KB	0.48×	0.8806
60	59.2 KB	0.42×	0.9145
50	53.6 KB	0.38×	0.9133
40	48.0 KB	0.34×	0.8740

Already-compressed JPEG

1440 × 1800 JPEG, 338,114 bytes, downloaded from a social feed

Quality	File size	vs 95	Similarity
100	1.40 MB	2.97×	0.9997
95	481.7 KB	1.00×	0.9990
92	413.9 KB	0.86×	0.9982
90	399.6 KB	0.83×	0.9981
85	362.4 KB	0.75×	0.9958
80	331.1 KB	0.69×	0.9889
75	299.3 KB	0.62×	0.9842
70	276.7 KB	0.57×	0.9799
60	239.4 KB	0.50×	0.9689
50	218.9 KB	0.45×	0.9582
40	185.1 KB	0.38×	0.9423

Five things the numbers say

1. Quality 100 is a trap, on every single file

It cost between 2.4 and 3.0 times the bytes of quality 95 on all five pictures, and bought between 0.0007 and 0.0016 of similarity. There is no picture in this set, and probably no picture at all, where that is a trade worth making. The setting exists because the format allows it, not because anybody should pick it.

2. The knee is between 95 and 85, and it is steep

On the phone photo, going from 95 to 90 removes 24% of the file for 0.0038 of similarity. Going from 90 to 85 removes another 30% for 0.0044. Those are the two best trades on the whole table. Below 80 the file keeps shrinking but the returns flatten: 60 to 50 saves 15% and 50 to 40 saves 17%, while the score is falling as fast as it was at the top.

3. A file that has been compressed once has very little left to give

The social-feed JPEG arrived at 338 KB. Re-encoding it at quality 85 produced 371 KB and at 90 produced 409 KB. Both are larger than the original. It only broke even around quality 80, and to get a real saving it had to go to 60, where the score had fallen to 0.9689 and the artefacts of two separate compressions were sitting on top of each other.

The same thing is true of phone photos, just less dramatically. That 1.87 MB file re-encoded to 1.99 MB at quality 95, so the phone had already saved it at just under 95. This is why "compress my photos losslessly" disappoints: the slack people are hoping to find was taken before they ever touched the file.

4. JPEG and flat artwork do not get along, at any setting

The logo scored 0.9284 at quality 100 and never got meaningfully better, because JPEG rings around hard edges and no quality number turns that off. Every other file in the set clears 0.99 somewhere. This one cannot, so a compressor that promises "visually lossless" has nothing honest to offer it. The answer for flat artwork is PNG, or WebP if the PNG is too heavy.

The logo also produced the one result in the whole sweep that goes the wrong way: quality 70 scored 0.8806 while quality 60 scored 0.9145. Lower quality, higher score. JPEG's quantisation tables are not perceptually monotonic on hard edges, so a particular table can happen to land more kindly on a particular pattern of edges. It is published here rather than smoothed away because it is a real property of the format, and because it is the reason a bisecting search for a quality target can land a step or two off on artwork.

5. A screenshot compresses well and still looks wrong

This is the row that surprised me. The 1.61 MB screenshot came down to 427 KB at quality 90 and scored 0.9903, which on paper is an excellent result. Look at it at 100% and the text has a faint halo around every letter. The metric is measuring structure, and ringing beside a hard edge is structurally small even when it is the first thing your eye catches. So this is a case where a number and a person disagree, and the person is right. Use PNG for text.

So which number should you actually type?

If the picture is	Use	Because
A photo for a web page	80 to 85	Roughly half the bytes of 95, and nothing visible at the size a page shows it.
A photo someone will zoom into	90	The last setting where the busiest tiles still clear 0.99 on a normal photograph.
A photo you will edit again	PNG, or 95	Every save is another generation. Keep the original if you possibly can.
An email attachment or a form upload	Whatever fits	Name the size and let a tool find the quality. Guessing at a number to hit 2 MB wastes more time than it saves.
A screenshot, a logo, a chart	Not JPEG	Ringing on hard edges, at every quality the format has. PNG, or WebP.
Already a compressed JPEG	Leave it	Unless you are going below 80, you will spend bytes recording somebody else's artefacts.

How other tools pick for you

Most of them do not let you pick at all. Of the five tools ranking for "image compressor" that I ran on the same 1.87 MB phone photo on the same day, three offered no quality control whatsoever, one offered a number you had to apply and re-check by hand, and one offered a full codec panel aimed at engineers. Their outputs on that file were 397 KB, 576 KB, 771 KB, 538 KB, and one that returned a file 1% larger than the one it was given without mentioning it.

Read those against the phone photo table above and you can work out what each of them chose. 397 KB sits near quality 45. 576 KB sits near 65. 771 KB sits near 77. None of them told anybody that, which is the actual problem: they are all making a decision on your behalf and none of them will say what it was.

Re-run it yourself

The metric this used is the same one the image compressor runs on your own files, and it prints the score next to every result. Open a picture, switch to Quality, and walk the slider down while watching the file size and the number beside it. On your photograph the knee will be in a slightly different place than it is on mine, which is the whole reason the tool measures instead of assuming.

These figures are dated because browsers change. Chrome's JPEG encoder is not fixed, and a release that retunes it moves this entire table. If you are reading this a year from now, treat it as a shape rather than as a set of constants, and re-run the sweep.