If I resize a photo to 50%, is the file half the size?

No. Scale 50% on the Pathine Image Resizer is half the width and half the height. That is 25% of the pixels, not 50% of the bytes. We ran the same 20-file set from the quality-80 test through a 50% linear resize. The 17 photo JPEGs landed at a median 25.4% of the original file. Half would have been 50%.

This is a file-size test, not a beauty contest. We did not score sharpness. We resized, re-encoded, and weighed. If you want to see whether your photo still looks like your photo, drop it on the resizer and look. The table is ours.

Half of each side is a quarter of the grid

A 4000×3000 picture has 12 million pixels. Cut both sides in half and you have 2000×1500: 3 million pixels. 50% × 50% = 25%. “Half the file” is the wrong model. Bytes follow the grid, then the encoder, then whatever was already in the file.

The Pathine resizer keeps the original format. A JPG stays a JPG. A PNG stays a PNG. It does not convert anything on the way through. That matters for the two screenshots.

What we actually did

Same twenty files as the quality-80 experiment: fourteen Unsplash photographs, two photographs with readable signage, two UI screenshots saved as PNG, one already-small 800×600 web JPEG, and one large phone-like JPEG (4032×2678).

Each file was resized 50% on each side with Lanczos, then written back in its original format. JPEGs at quality 85, optimize on. PNGs kept as PNG. We used Pillow, which uses libjpeg. Pathine’s resizer uses the browser canvas. Same idea, not bit-identical. If you rerun a file in the tab you will not get our exact byte counts. You should get the same shape.

The photographs followed the pixel math

Seventeen photo JPEGs. After a 50% linear resize, the median file was 25.4% of the original bytes. The range was 16.5% (food) to 28.3% (night). That is the 25% grid, plus a little encoder weather. Not half.

The spotlight phone file makes the wrong model obvious. 4032×2678, 1,182,975 bytes. Half the file would have been 591,487. After 50% it was 2016×1339 and 317,488 bytes: 26.8% of the original. Same file, quality 80, same pixels, no resize: 989,605 bytes. The first knob on a 4000-pixel phone photo is the grid, not quality 80.

File	Pixels	Bytes	Of original
Phone JPEG, original	4032×2678	1,182,975	100%
Same file, "half the bytes"	-	591,487	50% (the wrong model)
50% linear, JPEG q85	2016×1339	317,488	26.8%
25% linear, JPEG q85	1008×669	88,945	7.5%
Quality 80, same pixels	4032×2678	989,605	83.7%

Push it further and the math keeps holding. 25% linear (1008×669) was 88,945 bytes, 7.5% of the original. Across the 17 photos the median at 25% linear was 7.0%. (0.25 × 0.25 = 6.25% of the pixels. Close enough that you can see the encoder in the leftover.)

The files that did not buy 75%

One file in the set was already a small web JPEG: 800×600, 71,743 bytes. At 50% it became 31,867 bytes, 44.4% of the original. That is nearer to half than to a quarter. There was not a 4000-pixel grid to throw away. Re-encoding the same pixels at quality 80 made it worse: 76,985 bytes, larger than the input. If the file is already crushed, 50% does not buy ~75%.

The two PNG screenshots, kept as PNG, stayed closer to half the bytes. Wikipedia UI: 367,976 → 223,466 (60.7%). Pathine UI: 288,891 → 145,078 (50.2%). PNG is a structure, not just a pixel count. Hard edges and flat color do not shrink the way a noisy photograph does. The resizer did not convert them to JPEG. That is why they look like a different experiment.

Resize first. Compress if a cap remains.

Quality 80 at the original pixel count left the 17 photos at a median 84.9% of the original. That matches the live quality-80 median, about a 15% save. Useful on a folder. The wrong first move on a 4032-pixel phone photo you need under a megabyte.

Get the grid honest, then compress only if a byte cap is still in the way. The Image Resizer has a Scale 50% control for the first job. The Image Compressor is the second job. Both run in the browser. The image is never uploaded.

A few straight answers