Original measurement · 12 October 2026

What do 50 KB and 100 KB do to real photos?

We encoded three licensed photographs as JPG, WebP, and AVIF at each cap. The table gives real file bytes and pixel dimensions; the sample images let you inspect detail yourself.

By ImageConvertNow Research · 5 minute read

The short result

All 18 outputs met their stated caps. We used 50 and 100 KiB, meaning 51,200 and 102,400 bytes. The encoders often finished below the cap. Output dimensions and visible detail changed with the format and scene.

These results do not establish a universal format winner. Quality numbers mean different things in each codec, and this test did not use a viewer study.

Look at the same photograph

This fruit pie is one of the three sources. Open an output at full size to inspect edges, texture, and any loss of detail. The files below are the measured artifacts, served without a second image optimization pass.

50 KiB limit

Fruit pie encoded as JPG under 50 KiB
JPG · 48.2 KiB · 1120 × 747 px
Fruit pie encoded as WebP under 50 KiB
WebP · 49.2 KiB · 1360 × 907 px
Fruit pie encoded as AVIF under 50 KiB
AVIF · 47.9 KiB · 1600 × 1067 px

100 KiB limit

Fruit pie encoded as JPG under 100 KiB
JPG · 99.1 KiB · 1600 × 1067 px
Fruit pie encoded as WebP under 100 KiB
WebP · 96.4 KiB · 1600 × 1067 px
Fruit pie encoded as AVIF under 100 KiB
AVIF · 99.9 KiB · 1600 × 1067 px

All measured outputs

Source images were normalized to 1600 px wide before this test. The “quality” column records the encoder setting selected by the search; it is not a cross-format quality score.

PhotoCapFormatActual sizePixelsQuality settingFile
Fruit pie50 KiBJPG48.2 KiB1120 × 74751Open
Fruit pie50 KiBWebP49.2 KiB1360 × 90746Open
Fruit pie50 KiBAVIF47.9 KiB1600 × 106746Open
Fruit pie100 KiBJPG99.1 KiB1600 × 106762Open
Fruit pie100 KiBWebP96.4 KiB1600 × 106777Open
Fruit pie100 KiBAVIF99.9 KiB1600 × 106765Open
Architecture50 KiBJPG49.4 KiB640 × 48067Open
Architecture50 KiBWebP49.7 KiB640 × 48062Open
Architecture50 KiBAVIF49.0 KiB640 × 48053Open
Architecture100 KiBJPG99.7 KiB1120 × 84053Open
Architecture100 KiBWebP99.6 KiB1120 × 84052Open
Architecture100 KiBAVIF97.0 KiB1600 × 120040Open
Mountain landscape50 KiBJPG49.8 KiB880 × 49548Open
Mountain landscape50 KiBWebP49.3 KiB640 × 36071Open
Mountain landscape50 KiBAVIF49.3 KiB640 × 36056Open
Mountain landscape100 KiBJPG99.9 KiB1120 × 63061Open
Mountain landscape100 KiBWebP98.8 KiB880 × 49576Open
Mountain landscape100 KiBAVIF99.7 KiB1120 × 63043Open

Method and limits

  1. We downloaded three CC0 photographs, verified their SHA-256 checksums, applied orientation, and made 1600 px wide JPG reference files at quality 94. Normalization removed original EXIF and GPS.
  2. For each source, cap, and format, a local Sharp encoder searched integer quality 40–90 and, when needed, smaller widths at 85%, 70%, 55%, 40%, or 30% of 1600 px. It kept the largest tested size and highest tested quality that fit.
  3. We counted encoded file bytes and read output pixel dimensions. No human image-quality rating or browser download speed was measured. The AVIF output came from this lab script; the target-KB tool currently offers JPG and WebP.

The reference photos were already JPEGs. Re-encoding cannot recover detail the camera or original JPEG removed. Photographs with text, transparent backgrounds, noise, or different colors may behave very differently. Browser encoders can also produce different bytes from this server-side Sharp run.

Source photographs and reuse

The exact hashes, settings, and rerun commands are recorded in the research methodology.

Try your own image

Set the destination’s real limit, inspect the downloaded bytes and pixels, and keep a copy of the original.