Resize image to 100KB: what happens to its shape?
“100KB” is a byte ceiling, not a width-and-height instruction. Seven inputs — from a square photo and a wide banner to a scanned page and a 24-megapixel portrait — were each sent through the same browser compressor at 102,400 bytes, three times. Some kept every pixel; others came back at less than a tenth of their starting pixel count. Across the set, output aspect ratios shifted by no more than 0.096%. The pixel geometry stayed close to its original shape; how much of that geometry survived depended on the file.
Seven inputs, one byte ceiling
- The output is not one standard size. Two files kept their original dimensions (600 × 600 and 2,400 × 1,200); resized outputs included 731 × 1,035 for the A4 scan and 1,031 × 1,547 for the 4,000 × 6,000 photo.
- Pixel retention ranged from 6.65% to 100%. A 600 × 600 photo kept all 360,000 pixels; the 24MP portrait kept 1,594,957 of 24,000,000.
- The frame shape barely moved. The largest measured aspect-ratio drift was 0.09553%, on the A4 scan. The results are consistent with one scale applied to both sides and each side rounded to a whole pixel.
- Same bytes do not mean same measured error. At the same target, the 600 × 600 photo's output-grid MAE was 3.2633 per RGB channel; the A4 page's was 5.9360. Pixel retention and reconstruction error answer different questions, so both are shown.
- The files were repeatable; the clock was not. Each image was run three times. Bytes, dimensions and error metrics matched exactly within each set; the tool's elapsed time varied by run.
Measured 12 November 2026 in Chrome 157.0.8103.38 on Windows 11, using this site's browser-side compressor. No cropping or dead-frame analysis was part of this experiment.
What was measured: seven local sample files with different pixel dimensions, aspect ratios, formats and content. Each was loaded into the same local copy of the compressor and set to JPG at 100 KB, which the tool interprets as 102,400 bytes. Each run used a fresh tab. Input bytes were checked from the filesystem and browser File object. Output bytes were checked three ways: the tool report, FileReader, and the decoded output Blob. Output dimensions were checked against createImageBitmap. Reconstruction error was calculated after drawing the orientation-correct original to the exact output dimensions, then comparing that pixel array with the output decoded through both createImageBitmap and an HTMLImageElement. Timing is the tool's own “Done in … ms” reading; it is an environment measurement, not a file property.
What the same 100KB limit returned
The byte target was fixed. The inputs were not: they included a square 600-pixel photo, a 2:1 banner, two landscape photographs, an A4 scan, a portrait photograph and a 4,000 × 6,000 photograph. The table records the output dimensions the tool actually returned, rather than suggesting that “100KB” has a standard pixel size.
| Input | Source dimensions / bytes | Output dimensions / bytes | Bytes reduced | Pixels retained | JPEG q | MAE | Aspect drift | Tool ms ×3 | Wall ms ×3 |
|---|---|---|---|---|---|---|---|---|---|
| Square photo, JPG | 600 × 600 / 158,214 B | 600 × 600 / 102,312 B | 55,902 B / 35.3% | 100.00% | 0.87344 | 3.2633 | 0.00000% | 98 / 100 / 99 | 220 / 240 / 217 |
| Wide banner, JPG | 2,400 × 1,200 / 124,166 B | 2,400 × 1,200 / 101,538 B | 22,628 B / 18.2% | 100.00% | 0.92031 | 0.0474 | 0.00000% | 559 / 456 / 675 | 714 / 669 / 871 |
| Landscape photo, JPG | 2,592 × 1,944 / 926,328 B | 1,621 × 1,215 / 102,346 B | 823,982 B / 89.0% | 39.09% | 0.40469 | 3.0678 | +0.06173% | 4,927 / 4,376 / 3,266 | 5,013 / 4,445 / 3,328 |
| Night photo, JPG | 3,000 × 2,000 / 689,299 B | 2,482 × 1,655 / 102,087 B | 587,212 B / 85.2% | 68.46% | 0.40469 | 1.8834 | −0.02014% | 3,977 / 3,993 / 4,330 | 4,205 / 4,060 / 4,518 |
| A4 scan, PNG | 2,480 × 3,508 / 944,090 B | 731 × 1,035 / 101,415 B | 842,675 B / 89.3% | 8.70% | 0.40469 | 5.9360 | −0.09553% | 1,522 / 1,875 / 1,617 | 1,670 / 2,091 / 1,752 |
| Portrait photo, JPG | 2,000 × 2,800 / 1,736,969 B | 1,039 × 1,454 / 101,686 B | 1,635,283 B / 94.1% | 26.98% | 0.40469 | 4.2795 | +0.04127% | 2,061 / 1,970 / 1,885 | 2,258 / 2,082 / 1,958 |
| Large portrait photo, JPG | 4,000 × 6,000 / 3,492,678 B | 1,031 × 1,547 / 102,207 B | 3,390,471 B / 97.1% | 6.65% | 0.40469 | 4.0038 | −0.03232% | 5,389 / 3,544 / 4,433 | 5,477 / 3,741 / 4,523 |
Target: 102,400 bytes. Bytes reduced = source bytes − output bytes; percent = reduced bytes ÷ source bytes × 100. Pixel retention = (output width × output height) ÷ (source width × source height) × 100. JPEG q is the browser encoder parameter, not a visual score. MAE is mean absolute RGB-channel difference on the output-sized grid. Aspect drift = ((output width ÷ output height) ÷ (source width ÷ source height) − 1) × 100. “Tool ms” is the verdict timer; “Wall ms” is an independent Date.now() bracket around run(), read before the pixel-error calculation. Each column lists all three readings in run order.
Two files did not need a dimension change: the 600 × 600 photo and the 2,400 × 1,200 banner stayed at their starting sizes. The other five came back smaller on both sides. That split is a useful reminder that a byte target does not itself tell you whether the compressor will spend its effort on fewer pixels, lower JPEG quality, or both. The result report records the output it found for each particular input.
The shape stayed; the pixel count did not
For each file, aspect drift is ((output width ÷ output height) ÷ (source width ÷ source height) − 1) × 100. The square photo and banner stayed at 0.00000%. For the 2,480 × 3,508 scan, the measured change was −0.09553%; for the 2,000 × 2,800 portrait it was +0.04127%; for the 4,000 × 6,000 photo it was −0.03232%. Across all seven inputs, the absolute drift stayed at or below 0.09553%.
This is a small geometry effect, not a crop. The compressor's resize path uses one scale for width and height, then rounds each calculated side to a whole-pixel dimension. Whole pixels are unavoidable, but rounding the two sides separately can make the ratio move slightly. In this sample, the A4 scan showed the largest shift: 2,480 × 3,508 became 731 × 1,035. The page does not claim that every image, encoder or browser will have the same maximum drift.
One byte budget, very different amounts of the frame
Pixel retention is an area calculation, not a width calculation. The 4,000 × 6,000 portrait returned at 1,031 × 1,547. That is 1,594,957 output pixels out of 24,000,000, or 6.65% of the starting count. Its width and height each remained about 25.8% of their original lengths. The A4 scan kept 756,585 of 8,699,840 pixels, or 8.70%, while each side remained about 29.5% of its original length.
By contrast, the night photo returned at 2,482 × 1,655, keeping 4,107,710 of 6,000,000 pixels — 68.46%. The square photo and banner kept all their pixels. Those are measured outcomes for these seven files, not a ranking of image categories: the files differ in source size and content, so this experiment cannot isolate aspect ratio or subject matter as the cause of the different pixel counts.
“Quality” needs two separate readings
The compressor's resultQuality is a browser encoder parameter. It is not a score from a person
looking at the image. Five of the seven resized outputs used the same internal setting, 0.4046875; the
banner used 0.9203125, and the square photo used 0.8734375. A single setting number cannot describe the
effect of changing both the encoded pixels and, for some files, the dimensions.
The table therefore separates two facts. “Pixels retained” is output width × height divided by source width × height. MAE is the mean absolute difference between each output RGB channel and the corresponding source pixel after drawing the orientation-correct source onto the exact output-sized grid. It measures encoding/reconstruction error at the final dimensions; it does not also count the spatial detail lost by downsampling. The landscape MAE was 3.0678 per RGB channel at 1,621 × 1,215, while only 39.09% of the source pixel count remained. Read those together, not as interchangeable definitions of visual quality.
The output error was calculated twice: once after createImageBitmap decoding and once after HTMLImageElement decoding. The two paths returned identical MAE, MSE and PSNR for every row. That cross-check confirms the output decode route did not change the reported pixel values; it does not turn a pixel statistic into a subjective quality rating.
Byte reduction and elapsed time
All seven outputs landed at or below the 102,400-byte limit, from 101,415 to 102,346 bytes. The amount removed from the input varied widely: the banner lost 22,628 bytes (18.2% of its 124,166-byte source), while the large portrait lost 3,390,471 bytes (97.1% of its 3,492,678-byte source). Byte saving is calculated as source bytes minus output bytes, divided by source bytes for the percentage.
Runtime is less repeatable than the file itself. The banner took 456–675 ms in the tool's three readings; the 4:3 photograph took 3,266–4,927 ms; the large portrait took 3,544–5,389 ms. Those are the observed ranges from the three values in the table, not service-level promises. The output bytes, dimensions, encoder setting and error values were identical across the three fresh-tab runs for each input even when elapsed time moved.
What to check before you use the result
- Check the returned width and height. A 100KB ceiling cannot promise that a particular form's minimum dimensions will still be met. Compare the downloaded file's dimensions with the form's requirement after resizing.
- Check how much pixel area remains. A result can keep the frame's shape while retaining only a small fraction of its pixels. Aspect-ratio preservation is not the same as retaining resolution.
- Inspect the part that matters at its final size. A scan with 8.70% of its original pixels retained is a different outcome from a square image that kept all its pixels, even though both satisfy the same byte ceiling.
- Read the exact byte count if a form is strict. “100KB” in this tool is 102,400 bytes. The result should be checked against the destination's actual byte rule rather than the rounded label.
Questions this page answers
Will every image come back with the same dimensions?
No. At 102,400 bytes the seven measured outputs ranged from 600 × 600 to 2,482 × 1,655 among these particular inputs, with five resized outputs ranging down to 731 × 1,035 and 1,031 × 1,547. A byte ceiling does not specify either side length.
Will resizing make my image too wide or too tall?
Not by much in this measurement: the output aspect ratio moved between −0.09553% and +0.06173% where it changed at all. That is the observed rounding drift for seven files in this browser run, not a universal guarantee. Check the actual downloaded dimensions if exact geometry matters.
Why did one image keep every pixel and another lose most of them?
The seven samples were not identical pictures with one property changed, so this run cannot assign the difference to a single cause. It shows the practical result instead: at the same 102,400-byte cap, two inputs kept every pixel, while the A4 scan kept 8.70% and the large portrait 6.65%. Image content, source dimensions, format and the compressor's byte search all contribute; a new controlled experiment would be needed to isolate any one factor.
Does the MAE column tell me whether a picture looks good?
No. MAE is the average per-channel difference after the orientation-correct source is drawn to the output dimensions and compared pixel by pixel with the decoded output. It cannot by itself express legibility, edge appearance, subject importance or the detail lost by retaining fewer pixels. Use it alongside pixel retention and inspect the result at the dimensions you will actually submit.
Can the same image return different bytes if I repeat the resize?
Not in these runs. Each input was run three times in fresh tabs; for every input, all three output byte counts, dimensions, quality parameters and two-path error measurements were identical. The elapsed time moved, as the three readings show.
This page measures the resize wording at 100KB: output dimensions, retained pixel area and aspect-ratio drift. The separate compress image to 100KB page asks a different question about where a smooth dead band spends the byte budget and how a whole-frame average can hide subject-region error. Its crop comparison is not used as data here.
For the same “resize image to” intent at a tighter 20KB ceiling, see the ten-file 20KB measurement. That page is about repeating one-file passes for a folder; this page is about the geometry and pixel area returned by one 100KB target.
Sending a JPG by email raises a separate privacy question: whether compression removes GPS, capture-time, camera and orientation EXIF fields. The email attachment test checks those fields before and after re-encoding with two independent readers; it does not use resize or pixel retention as its main measure.
For a controlled content-variation test rather than seven different inputs, see the synthetic-noise 100KB compression measurement. It starts from one photograph, varies RGB pixels synthetically and records file bytes, error and time; it does not make geometry or pixel retention its main result.
Measurement provenance: local file samples in _testimg; compressor source site/app.js;
browser Chrome 157.0.8103.38 on Windows 11; test date 12 November 2026; 100KB target = 102,400 bytes;
three fresh-tab runs per input. Raw run data and two-way checks were recorded before writing this page.