Resize first, or let the compressor shrink it?
A form says 100 KB. You can type that into the compressor, leave Allow shrinking ticked, and let it make the photo smaller in pixels until the file fits. Or you can resize the photo first and then compress it with Allow shrinking unticked. People ask which is better, and most forum answers say resize first.
We tried both routes on the same 25 photos. When the form names a pixel size, resizing to that size comes first. When it names only a file size, the compressor alone reached every target for every photo, 100 of 100 files, and kept more pixels; resizing first gave cleaner pixels but fewer of them, and at 20 KB no long side we tried worked for every photo.
What people run into
- A Quora answer on getting a picture under 100 KB says cutting the pixel size saves the most bytes for the least visible loss. (user report) Partly true. At 100 KB every long side up to 1,024 px reached the target for at least 24 of 25 photos and scored higher on our similarity score than the compressor's own file. But those files kept 10% of the pixels or less, against a median 30% for the compressor alone.
- Someone on Quora asks why a photo was rejected after it was compressed to 20 KB. Answers there point at the pixel size. (user report) At 20 KB the compressor alone made every photo smaller in pixels: the long side ended between 333 and 1,844 px, a median 612 px. If the form also sets a minimum pixel size, check it under the result.
- Another Quora question asks how to get a JPG under 100 KB without making it smaller in pixels. (user report) That depends on the pixel size. Left to itself, the compressor had to shrink 21 of our 25 photos to reach 100 KB. Resized to 800 px on the long side they all fit, and at 1,024 px 24 did; the one that missed was a close-up texture.
- A Quora answer suggests setting a small longest side in Paint first, then lowering the JPG quality until the file is a few KB. (user report) The smallest long side we tried, 640 px, fit 20 KB for 15 of 25 photos. The rest stayed over even at the lowest quality, so a few KB is not realistic for detailed photos at that size.
- An answer on Photography Stack Exchange says re-saving a JPG almost always makes it smaller. (user report) Not for a file that is already small. When the resized file already fit, the compressor saved it again, and 89 of 158 came out bigger.
We read these pages through search results; Quora and Stack Exchange show a bot check to our test machine. They are what people say, not rules, and we use no number from them.
How to check it with our tools
- Open Resize, choose Pixels and leave Keep aspect ratio ticked. Type the long side: the width for a landscape photo, the height for a portrait one.
- Press Resize image and download the result.
- Open Compress and add the resized file. Untick Allow shrinking, type the target and press Compress image.
- Under the result, check the file size and the pixel count. Target not reached means that long side is too big for that target.
- To compare, add the original photo to the compressor with Allow shrinking ticked and the same target. Look at both files at full size, not only at the numbers.
What we measured
We ran 25 CC0 photos, each at least 2,048 px on the long side, through both routes at 20 KB, 50 KB, 100 KB and 200 KB. Route one: the compressor's default JPG mode with Allow shrinking ticked. Route two: resize to a long side of 640, 800, 1,024, 1,200 and 1,600 px with Keep aspect ratio on, then the compressor with Allow shrinking unticked. Both routes always hand back a file; we count it as reached when it is at or under the target.
Files that reached the target, of 25
| Route | Pixels kept (median) | 20 KB | 50 KB | 100 KB | 200 KB |
|---|---|---|---|---|---|
| Compressor alone, shrinking on | 4.5% to 63.1% | 25/25 | 25/25 | 25/25 | 25/25 |
| Resize to 640 px, then compress | 3.8% | 15/25 | 25/25 | 25/25 | 25/25 |
| Resize to 800 px, then compress | 6.0% | 9/25 | 22/25 | 25/25 | 25/25 |
| Resize to 1,024 px, then compress | 9.8% | 6/25 | 16/25 | 24/25 | 25/25 |
| Resize to 1,200 px, then compress | 13.5% | 5/25 | 13/25 | 22/25 | 25/25 |
| Resize to 1,600 px, then compress | 24.0% | 3/25 | 6/25 | 16/25 | 23/25 |
Pixels kept tells you how much of the original's pixel count the final file has. For the compressor alone it depends on the target.
Source: our test on 2026-11-10 (harness eacd79c, site code eacd79c), headless Chromium 145 on a desktop Mac, 25 CC0 photos. How we test
Similarity of the files that reached (median)
| Route | 20 KB | 50 KB | 100 KB | 200 KB |
|---|---|---|---|---|
| Compressor alone, shrinking on | 0.927 | 0.939 | 0.948 | 0.956 |
| Resize to 640 px, then compress | 0.976 | 0.970 | 0.988 | 0.990 |
| Resize to 800 px, then compress | 0.988 | 0.966 | 0.982 | 0.989 |
| Resize to 1,024 px, then compress | 0.987 | 0.972 | 0.971 | 0.985 |
| Resize to 1,200 px, then compress | 0.990 | 0.980 | 0.967 | 0.982 |
| Resize to 1,600 px, then compress | 0.980 | 0.986 | 0.969 | 0.972 |
Similarity compares each file with the original scaled to the same size, so it shows the damage compression did at that size. It does not count the detail lost by having fewer pixels; read it next to pixels kept. Photo by photo, the resize-first file scored higher than the compressor's own file in 346 of 355 cases where it reached the target.
Source: our test on 2026-11-10 (harness eacd79c, site code eacd79c), headless Chromium 145 on a desktop Mac, 25 CC0 photos. Similarity is our own 8×8-block luma score (SSIM): 1.000 means no visible change. How we test
The long side to type for each target
| Target | Largest long side that reached for all 25 | Its similarity (median) | Compressor alone: long side it picked (median) | Pixels kept: resized, compressor alone |
|---|---|---|---|---|
| 20 KB | None of ours: 640 px reached 15 of 25 | – | 612 px | –, 4.5% |
| 50 KB | 640 px | 0.970 | 1,096 px | 3.8%, 12.9% |
| 100 KB | 800 px | 0.982 | 1,633 px | 6.0%, 30.5% |
| 200 KB | 1,200 px | 0.982 | 2,309 px | 13.5%, 63.1% |
Source: our test on 2026-11-10 (harness eacd79c, site code eacd79c), headless Chromium 145 on a desktop Mac, 25 CC0 photos. Similarity is our own 8×8-block luma score (SSIM): 1.000 means no visible change. How we test
When resizing first wins
Resizing first wins when the form fixes the pixel size or shows the photo small. Then all the bytes go to pixels that will be seen. At 100 KB, resizing to 800 px gave a median similarity of 0.982, against 0.948 for the compressor alone. It kept 6.0% of the pixels; the compressor kept 30% at a lower quality setting, a median 0.44.
It is also less work for the tool. Resizing first was faster in 500 of 500 runs: a median 9 ms to 87 ms for both steps, against 259 ms to 294 ms for the compressor alone. These times are from a desktop Mac; phones are slower. You still open two tools and download twice.
When it does not
When the form gives only a file size, the compressor alone keeps more of the photo. At 200 KB it kept a median 63% of the pixels, a long side of 2,309 px. The largest long side that reached for every photo, 1,200 px, kept 13.5%. If the photo will be viewed large, that detail is worth more than a cleaner small file.
A long side that is too big for the target misses. With Allow shrinking unticked there is one round: the quality stops at 0.36 and you get a file over the target, marked Target not reached. In our test: at 20 KB, 640 px reached 15 of 25; at 50 KB, 800 px reached 22 of 25; at 100 KB, 1,024 px reached 24 of 25; at 200 KB, 1,600 px reached 23 of 25.
Close-up textures missed first. At each target's first long side that missed, 10 of the 16 misses were close-up textures, though only 4 of our 25 photos are textures. Fine detail costs bytes at any size.
At 20 KB no long side from 640 px up reached for every photo; 640 px came closest with 15 of 25. The compressor alone reached all 25 by going down to a long side of 333 px. If you need more pixels than that, crop to the subject first, so fewer bytes are spent on background. The 20 KB page shows the photos by kind.
If the resized file already fits
In 158 of 500 runs the resized file was already under the target before we compressed it. The compressor saved it again anyway, at quality 0.92: 89 came out bigger and 67 smaller, and all 158 stayed under the target. If the resized file already fits, you can upload it as it is.
What to do
- Read the form: does it give a pixel size, a file size, or both?
- Pixel size given: crop to its shape if needed, resize to it, then compress with Allow shrinking unticked. The crop page, the 1920 × 1080 page and the 1080 × 1080 page show how.
- Only a file size, and the photo will be shown small: resize to the long side in the table above for your target, then compress with Allow shrinking unticked.
- Only a file size, and you want the most detail: compress the original with Allow shrinking ticked and let the compressor pick.
- At 20 KB or less, expect a small photo either way. Check the pixel size under the result against any minimum the form sets.
- Before you upload, check the file's size in bytes, its pixel size, and the picture at full size.
What our test covers
The numbers come from our benchmark harness, which runs this site's own code in a browser on a desktop Mac. Reached means at or under the target in bytes, with 1,000 bytes to a KB. We did not upload anything to a real form.
The compressor-only runs repeat settings from our test on 2026-11-10, and their bytes matched it in 100 of 100. A second run on 3 photos matched the first in 72 of 72. See how we test.
Other pages have their own tables, so we link instead of repeating them: compress image for every target with shrinking on and off, resize image for common sizes, the 20 KB, 50 KB, 100 KB and 200 KB pages for real uploads at those limits, and the image size guide for platform sizes.
Sources
User reports (what people say, not rules):
- Quora: How do I compress a picture to 100 KB? (user report)
- Quora: Why does my photo get rejected even after compressing it to 20 KB? (user report)
- Quora: How can you compress a JPEG under 100 KB and keep its dimensions? (user report)
- Quora: How can I reduce the size of photos from MB to a few KB? (user report)
- Photography Stack Exchange: JPG and file sizes, basic facts (user report)
Last updated: