Blog

Notes on smaller images

How the encoders decide, when a format wins, and what makes a page load fast. Written by Mozex, who runs Iminify.

RSS feed

Latest post

Bar chart of the resized files WordPress 7.1.2 made on the server and in Chrome: 691 and 640 KB for a 1800 px photo, 1,942 and 2,193 KB for its 6000 px version, 553 and 651 KB for a PNG screenshot.

Latest post

Does WordPress compress images? What WordPress 7.1 does to your upload

We uploaded the same photo to a fresh WordPress 7.1.2 site twice, both times from Chrome. The file we sent, 832 KB, was stored byte for byte both times. From it WordPress made five resized copies at JPEG quality 82. Through Media > Add Media File those copies came to 691 KB. Through the Upload button on an Image block they came to 640 KB, because in 7.1 that button has the browser make the copies instead of the server. So does WordPress compress images automatically? Not the file you upload, which is stored byte for byte. It re-encodes the resized copies it makes, the JPEG ones at quality 82. In our test a phone and a standard laptop screen downloaded copies of this photo, but a 2x laptop screen got the untouched original, so compressing it is still your job. Since 7.1, which program makes the copies depends on the button you press and the browser you press it in.

8 min read

All posts

ComfyUI's Flux Dev example render of a fox-eared girl in a maid dress holding a cake, captioned: 1,215,064-byte PNG to 125,684-byte WebP, and the workflow still loads in ComfyUI.

ComfyUI PNG to JPG loses the workflow. WebP and AVIF can keep it

ComfyUI's Flux Dev example image is a PNG of 1,215,064 bytes, and the two text chunks holding its prompt and workflow take 12,240 of them. The rest is 1024x1024 pixels stored without loss. Across the 92 PNGs in ComfyUI's examples repository that carry a workflow, the text was no more than 3.32 percent of any file, with a median of 0.62 percent. Converting to JPG shrinks the file, but ComfyUI's own loader can't read a workflow back out of a JPG. A WebP or AVIF can keep it, at about a tenth of the size. We took the text-to-image examples of ten models from ComfyUI's examples repository, made smaller copies several ways, and dropped the copies back onto ComfyUI 0.37.0's canvas to see which ones still held the workflow.

6 min read
Bar chart of mozex.dev's image bytes at Lighthouse's phone size: 63.7 KB in 2 files before scrolling, 653.5 KB in 9 files after, and a worked-out 107.1 KB with its own images resized and re-encoded for the phone and the hidden one skipped.

How to find large images on a website: three tools gave us three different lists

On 22 September 2026 we loaded mozex.dev, the site of Mozex Labs, which runs Iminify, at the phone size Lighthouse emulates, and listed its images three ways: Chrome's network log, Lighthouse and a console snippet. Before any scrolling, Chrome had fetched 2 image files, 63.7 KB. After we scrolled to the bottom, it had fetched 9 files, 653.5 KB. Lighthouse's phone runs requested 7 and never the two heaviest, 340.8 KB between them. The browser's own timing data put one image at 0 bytes. So the list you can trust comes from Chrome's Network panel, taken after a scroll. Every method here works on one page at a time, so run it on the pages you care about most.

8 min read
Line chart of the fjord photo's SSIMULACRA 2 score over 100 saves: ImageMagick levels off at 91.99 and Pillow at 69.77, while Pillow with 1 pixel cropped before each save and jpegli after mozjpeg's decoder both fall below -60.

Does a JPEG lose quality every time you save it? We saved five photos 100 times

Two of the tests that come up for this question disagree. Fstoppers opened a photo in Photoshop 2020 and saved it 99 times at maximum quality, and saw "significant quality loss after you save it six times". Improve Photography saved one 30 times at maximum quality, painting a pixel white each time, and found "no noticeable reduction in image quality. None." Both judged by eye. We opened a JPEG 100 times, copied it and zipped it, then saved five photos 100 times in a row in five programs and scored every save against the file we started from. The short answer: Opening, copying and zipping never changed a byte. In every same-setting run, no later save cost as much as the first. Saving again at the same setting, with no edits, then mostly stopped costing: at their defaults, by save 73, ImageMagick, Chrome and Pillow were writing identical files on all five photos, and mozjpeg on four. Cropping one pixel or turning the photo before each save kept eating it. One pairing of two JPEG libraries lost quality with every save: the jpegli encoder fed by mozjpeg's decoder. Iminify runs that pairing, so we tested our own tool too.

7 min read
Bar chart of one photograph in bytes: 852,461 as served, against Lighthouse's target of 45,084 at its phone slot and encodes of 47,876 (JPEG), 46,320 (WebP) and 41,735 (AVIF).

Improve image delivery in Lighthouse: what it replaced and how it counts savings

PageSpeed Insights ran Lighthouse 13.5.0 on our home page on 22 September 2026 and flagged "Improve image delivery" in the mobile report: "Est savings of 1,300 KiB". All of it came from one photograph. The fjord shot in our before-and-after comparison is on the page twice, as the 832.5 KiB original and as our own compressed copy at 555.3 KiB. Both files are 1800x1200, and the report says they're displayed at 637x425. Three later runs that day said 1,359 KiB and 364x243. If your old notes say "Serve images in next-gen formats" or "Properly size images", this is where they went: Lighthouse 13 folded four image audits into this one insight. And its savings aren't measured: each figure is arithmetic on bytes and pixels. We reproduced every number in that insight, made the file it asks for, and traced one reason the same page gets two answers.

8 min read
Bar chart for one 4080x3072 phone photo, measured with each vendor's token counter: 1,102 tokens on Gemini 3.8 Flash, 4,743 on Claude Opus 5.5 and 14,746 on GPT-5.6 at default detail.

How many tokens is an image? Claude, GPT and Gemini, measured on seven real files

A 12.5-megapixel phone photo counts 4,743 input tokens on Claude Opus 5.5, 1,102 on Gemini 3.8 Flash and 14,746 on GPT-5.6 at its default detail setting, over 13 times Gemini's count. We measured all three with the vendors' own token counters on 23 September 2026. And none of the three depends on how many bytes the file has. Claude counts pixels up to a cap, GPT-5.6 counts every pixel unless you ask for less, and Gemini 3 barely looks at the size.

7 min read
The fjord photograph from our test set above two bars: 3.07 MB as a PNG and 555 KB as a JPEG at quality 90.

Why is my PNG file so large? Four causes, measured

We took the fjord photograph from our test images, a 1,800 by 1,200 JPEG of 832 KB, and saved the same pixels as a PNG. It came to 3.34 MB at the default setting of Pillow, the Python imaging library. Through zopflipng, a slower lossless compressor, 3.07 MB. As a JPEG at quality 90 it's 555 KB, and it scores 84.22 on a perceptual scale where 80 means an average observer can't see the difference side by side. A photograph was the most expensive of the four causes in the comparisons below. The four: It's a photograph. It has more pixels than it will be shown at. It stores more per pixel than the picture needs: 16 bits per colour channel, or millions of colours where 256 would do. The program that saved it didn't compress it very hard. Each has its own fix, and the fix for one can be wrong for another. A JPEG rescues a photograph. Our desktop screenshot came out bigger as a JPEG than as a PNG through zopflipng.

7 min read
Bar chart: a 12.5 MP phone photo at JPEG quality 90 is 4,309,090 bytes as a file and 5,745,456 bytes as base64, past a dashed line at the 5,242,880-byte limit on Bedrock and Google Cloud.

Image exceeds 5 MB maximum? Claude counts the base64, not your file

Our 12.5-megapixel test photo, re-saved with jpegli at quality 90, is 4,309,090 bytes. That's under 5 MB, and it's still too big for Claude on Amazon Bedrock or Google Cloud. Anthropic's limit there is "5 MB (base64-encoded)", and base64 turns those 4,309,090 bytes into 5,745,456. The error compares the encoded size with 5,242,880 bytes, as in this one from a Claude Code issue: image exceeds 5 MB maximum: 5281812 bytes > 5242880 bytes. So the ceiling is 3,932,160 bytes of actual file on Bedrock and Google Cloud, and roughly 7.5 MB on the direct Claude API, whose limit is 10 MB. Separately, no side may pass 8000 pixels, or 2000 once a request carries more than 20 images. For photos, one step clears all of it: resize to 2000 pixels on the long edge and save it as JPEG.

8 min read
The harbour picture Nano Banana 2 generated at 4K, 5504x3072: 10.51 MB as sent, a quality-100 JPEG, and 1.58 MB re-encoded as a quality-82 JPEG holding 40 dB.

How big is a Nano Banana image? 52 files measured, from 512 px to 4K

We asked Nano Banana 2 for a 4K, 16:9 picture of a fishing harbour through the Gemini API on 23 September 2026. It came back as a 5504x3072 JPEG of 10.51 MB. The same request again gave 11.10 MB. Both files were saved at JPEG quality 100, the top of the scale. So, how big is a Nano Banana image? From Nano Banana 2 or Pro, a detailed picture is roughly 1 MB at 1K, 4 MB at 2K and 10.45 to 12.13 MB at 4K, and a flat illustration less. The original Nano Banana sends a PNG instead, about 2.1 MB for the same prompt at 1024x1024. Here are the 52 images of our test set, from all four Nano Banana models, and what five of them shrink to.

9 min read
The same app icon twice: as a 19,794-byte WebP with its transparency showing the background through, and as a 63,801-byte JPEG sitting on a white square.

Does converting PNG to WebP lose quality? Five files, every pixel checked

We converted five PNG files to WebP with the encoder forbidden to throw anything away, then compared every pixel against the original. All five kept every 8-bit pixel, and the files were between 28.6% and 77.3% smaller. So no, converting a PNG to WebP doesn't have to cost you anything you can see. The catch is that it isn't the conversion you're usually pointed at. Of the first four results for this question in September 2026, three recommend a quality number between 80 and 100, and in cwebp every one of those is a lossy setting. So is the button marked "compress PNG". Here's what each of them actually costs.

8 min read
Twelve sites and the image format Chrome got from each on 23 September 2026: WebP from Reddit, a Shopify store, Squarespace, BBC News, eBay; AVIF from Wix, YouTube, The Guardian, Unsplash; JPEG from Pinterest, Medium, Wikipedia.

Why do images save as WebP? What 12 sites sent Chrome, and how to get the JPG

The hero photo on the Allbirds home page has a file name that ends in .jpg. On 23 September 2026 the site sent Chrome a WebP of 572 KB. Ask the same image address for a JPEG and it sends one, 663 KB. That's why your saved image is a WebP. Many sites pick the format each time they send a picture, from a list of formats your browser says it can show. Twelve sites made it into our test: nine sent Chrome a WebP or an AVIF, and every one of those nine would also hand over a JPEG (JPG is the same format) if asked the right way. The four ways that worked are below the table.

8 min read
Bar chart of ten test images: each one as AVIF, sized against the same image as WebP at a matched quality score. The bars run from 29.8% on the transparent icon to 74.5% on the product photo.

AVIF vs WebP file size: ten images, one quality score, and where WebP still wins

Five of the fifteen pages we read for "avif vs webp file size" put AVIF 20 to 30% under WebP, ShortPixel among them. Six give no comparable figure, three put it between 11.76% and 50%, and one forum thread reports an AVIF twice the size. We put the ten images of our published corpus through cwebp and two builds of avifenc, bisecting each to the same SSIMULACRA 2 score of 80. The totals: 1,675.4 KB for WebP, 1,114.7 KB for a current AVIF, 33.5% smaller. So the headline is roughly right. It's also the least useful number here. If the verdict is all you want: AVIF for photographs and screenshots, WebP for lossless, and WebP again on our one transparent image once both encoders keep the alpha plane lossless.

8 min read
Four tiles reading mozjpeg q80, jpegli q84, cwebp q90 and avifenc q74: the quality each encoder needs to match mozjpeg at 80 on every one of six photographs.

JPEG 80 is not WebP 80: what quality means in four encoders

We set four encoders to quality 80 and pointed them at one photograph, an 1800x1200 shot of a fjord. jpegli scored 74.2 on the SSIMULACRA 2 scale, mozjpeg 74.8, cwebp 72.8, avifenc 85.5. One picture, one number typed into four tools, and nearly thirteen points between the best result and the worst. Quality 80 names four unrelated parameters that happen to share a range. We measured what each produces across ten public images, worked backwards to the number every encoder needs to land in the same place, and read all four sources to see why they disagree.

9 min read
Showing 1 to 12 of 15 results

Try it on your own images

Drop a photograph in, pick Smart, and compare the result with the original before you download. Free, no account needed.

Compress an image Optimize a whole page