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.

Latest post

Iminify blog cover on a blue gradient with a pixel pattern: "Should you compress before your CDN does?"

Latest post

Should you compress images before your CDN re-encodes them? Measured through Next.js, wsrv.nl and Photon

The Fjord, one of our five test photographs, is an 852,461-byte JPEG, the master every score below is measured against. Iminify's Smart level makes it a 568,598-byte JPEG. We sent both through Next.js 16.4.3's image optimizer at its default, WebP at quality 75. Next's WebP of the master weighed 321,790 bytes and scored 66.98 against the master on SSIMULACRA 2, where 100 means no difference from the master. Its WebP of the Smart file weighed 314,578 bytes and scored 64.30: 2.2 percent fewer bytes for 2.7 points. Should you compress before a CDN or optimizer re-encodes your image? In our tests, on five JPEG photographs through Next and wsrv.nl, only losslessly. A lossless repack, which made our uploads 2.4 to 5.6 percent smaller, changed nothing in 80 of 80 Next responses. And in 40 of 40 comparisons at no more bytes, asking Next for a lower quality setting scored higher than the lossy first pass. If nothing re-encodes after you, compress first.

7 min read

All posts

Four teal circles on a transparent background, above the same image converted to JPG with Pillow, where the strips behind them came out magenta, white, black and black.

Why does a transparent PNG turn black as a JPG? The colour hiding underneath

We made an 800x400 test PNG with four strips that look alike: the same teal circle on a transparent background, four times over (the fourth with a soft shadow). Then we turned it into a JPG with Pillow, Python's imaging library, using its convert("RGB"). The four strips came back magenta, white, black and black. Nothing was added. Those colours were already in the PNG, sitting under the transparency. A JPG can't store transparency, so whatever writes it has to put something behind the picture. Some tools paint white. Some just reveal the colour stored under the transparent pixels, which is often black. And Chrome's canvas, the drawing surface web pages use to edit images, paints black whatever was there, because the HTML standard says it must. If you want white, or any other colour, you have to choose it before the JPG is written. Iminify's JPG output puts white behind the picture, and PNG to WebP keeps the transparency instead.

8 min read
Ten squares: 4 filled for tools that kept the IPTC AI tag at their defaults, 6 hollow for tools that dropped it, beside the title Does compression remove the AI tag?

Does compression remove the AI tag Merchant Center asks for? 10 tools, WordPress and Iminify tested

Google's Merchant Center help says: "Don't remove embedded metadata tags such as trainedAlgorithmicMedia from such images. All AI-generated images must contain the IPTC DigitalSourceType trainedAlgorithmicMedia tag." (Merchant Center's help page is dated February 2024; we read it on 26 October 2026.) So we put that tag on two AI images, a harbour scene from Nano Banana 2 (a JPEG) and a bakery illustration from the original Nano Banana (a PNG), ran them through 42 command-line runs and Iminify, added three larger JPEGs for a WordPress 7.1.3 site, and read the tag back with ExifTool each time. Each tool's default decides whether the tag survives, and neither lossy nor lossless predicts it. Of the ten tools in our table, four keep the tag at their defaults and six drop it, and for nine of them we found an option that flips that. Iminify, which is our product, lost it at every level that compresses: it survived in 6 of 51 uploads, and those six came back byte for byte unchanged. One ExifTool command puts the tag back for 514 to 568 bytes and, on the nine files we checked, leaves every pixel alone.

8 min read
Two cards for the same photograph: the JPEG saved at quality 80, 449 KB, score 75.6, and the WebP made from it at quality 90, 531 KB, score 71.3.

Why is my WebP bigger than the JPG? Measured on 40 JPEGs and 4 PNGs

One photograph of our corpus, the Fjord, saved as a JPEG at quality 80 weighed 449,258 bytes. Converted to WebP at quality 90, it weighed 531,474, which is 18% more. Scored against the corpus master it came from (a JPEG saved at quality 92), the bigger file was also the worse picture: 71.3 on SSIMULACRA 2, a score where higher means closer to the master, against 75.6 for the JPEG. Google's WebP FAQ says a WebP can grow larger than its source and names three situations. We measured each on five photographs and four graphics. A WebP comes out bigger when its quality is set too high for the JPEG it came from, when it is lossless, or when a PNG already squeezed to 256 colours goes to lossy WebP. A fourth cause, which the FAQ doesn't list, is that WebP isn't always smaller than a good JPEG even at the same score. Whichever it is, keep the smaller file when the two look alike.

7 min read
Two cards under the title "Do AI images hurt SEO? The file can.": a Gemini 2K picture as delivered, 3.95 MB, largest paint 20.3 s; the same picture resized to 720 wide, 104 KB, 1.4 s, in Lighthouse's mobile test.

Do AI images hurt SEO? What Google's pages say, and what a 2K Gemini picture did to a page

We put Gemini pictures on a plain article page, one size at a time, and ran Lighthouse's mobile test on each. Straight from the generator, the 1K file (1.06 MB) took 6.2 seconds to become the page's largest paint (LCP), the 2K file (3.95 MB) took 20.3 seconds and the 4K file (10.51 MB) took 52.4 seconds. Google's target for that metric is 2.5 seconds. Do AI images hurt SEO? In the Google pages we read, nothing marks an image down for being AI-made. The file is another matter: the same 2K picture, resized and compressed to 104 KB, took 1.4 seconds. Iminify's compressor also drops the C2PA manifest that marks a Gemini file as AI-made, and Google's Merchant Center asks sellers to keep an IPTC tag that says the same.

8 min read
Two white cards on a blue gradient: WebP at quality 75, 35.1 KB, score 68.0, and AVIF at quality 47, 25.5 KB, score 68.8, beside the headline "A quality of 75 ships as WebP 75, or AVIF 47 if enabled".

What image quality does Next.js ship? WebP 75, AVIF 47 if you list it, and by default a 90 becomes 75

We built a Next.js 16.4.3 app with four images on one page, two of them declared with quality={90} and quality={100}. All 36 image addresses in the page's HTML said q=75. We also asked the image endpoint for q=90 directly, and it answered HTTP 400: "q" parameter (quality) of 90 is not allowed. That is Next 16's default: the list of allowed qualities is [75], and the component moves anything else to the nearest entry. This post follows the 75 to the encoder, in WebP and in AVIF if you switch it on, across 867 requests to a self-hosted /_next/image on nine source images. The default WebP puts one of our five photographs at 1080 px above 70, the "high quality" mark on SSIMULACRA 2, a perceptual score. AVIF at the same setting was 36.5 percent smaller across our 27 image and width combinations, and more than 3 points below WebP on score in 8 of them.

7 min read
Two enlarged crops of the same red text saved as JPEG at quality 80, one at 4:2:0 and one at 4:4:4, beside the title. The 4:2:0 crop has a duller, browner red.

Why is red text blurry in JPG and WebP? Chroma subsampling, measured

On a test page we made full of red text, no quality from 30 to 100 lifted a plain 4:2:0 encode (no -sharp_yuv) past 58.2 on the SSIMULACRA 2 scale, which runs to 100: JPEG (cjpegli) reached 57.9, WebP 55.2, AVIF (avifenc) 58.2. The same JPEG written at 4:4:4 scored 81.6 at quality 90. That gap is chroma subsampling: 4:2:0 keeps colour at a quarter of the detail that brightness gets, and 4:4:4 keeps all of it. It's why red text looks blurry in a JPG or a WebP. The fix is 4:4:4 for JPEG and AVIF, -sharp_yuv for lossy WebP (which narrows the gap), or lossless WebP on a flat page; What we'd use has the numbers and commands.

6 min read
Bar chart of the saving range for each kind of JPEG: camera and AI originals 8.6 to 16.3 percent, editor exports 5.1 to 9.4, web-sized files 2.4 to 7.7, and an Iminify Smart output 0.0.

How much does lossless JPEG compression save? 25 files, every pixel checked

Lossless JPEG compression with mozjpeg's jpegtran -copy none took between 0 and 16.3 percent off the 25 JPEGs we tested. Together they shrank 9.5 percent, from 164.1 MB to 148.5 MB, and the median file lost 6.6 percent. Every one still decodes to the same pixels. Where a file lands depends on where it came from. Camera and AI originals saved 8.6 to 16.3 percent, files exported from an editor 5.1 to 9.4, and thumbnails and sample photos sized for the web 2.4 to 7.7. The one file that Iminify's Smart level had already compressed, the Smart file below, saved nothing. Cloudflare's documentation says its lossless mode saves 21 percent on average "compared to unoptimized image files", with no figure for JPEG alone (page updated 21 April 2026). We didn't run it, and the best of ours saved 16.3.

8 min read
Grid of results for one iPhone photo sent in seven formats to three AI APIs: Claude's and OpenAI's read JPEG, PNG, WebP and GIF and refused AVIF, TIFF and HEIC; Gemini 3.8 Flash read all seven.

Can ChatGPT read HEIC? What five AI tools list, and what three APIs did with an iPhone photo

On 11 October 2026 we sent the same iPhone photo, a 1.7 MB HEIC of two greyhounds looking into a café, to three AI APIs (the interfaces developers use, not the chat apps). Gemini 3.8 Flash answered "Two leashed dogs looking inside a stylish, cozy restaurant." OpenAI's API replied "The image data you provided does not represent a valid image." Claude's API returned an error naming the four types it takes: JPEG, PNG, GIF and WebP. So can ChatGPT read HEIC? OpenAI's help page for ChatGPT lists three image types: PNG, JPEG and non-animated GIF. HEIC isn't one of them. Convert the photo to JPG before you attach it: JPEG, the same format as JPG, is on every format list we read from OpenAI, Anthropic, Google, Microsoft and xAI. Iminify's HEIC to JPG page converts it without an account. Two of the lists we read name HEIC: Google's image page for the Gemini API and xAI's FAQ for the Grok app.

7 min read
Bar chart of what Squarespace sent for 1,000-pixel copies: 368 JPG uploads came to 41.8 MB of WebP for Chrome against 55.1 MB of JPEG without WebP; 101 PNG uploads to 36.5 MB of lossless WebP against 17.1 MB of palette PNG.

Does Squarespace compress images? What it sent Chrome for 621 images

Yes. On 25 September 2026 we asked Squarespace's image server for 621 images from 85 Squarespace sites, once the way Chrome asks and once the way a browser without WebP support asks. On 84 of those sites Chrome got a WebP that Squarespace had made itself, for every JPG and PNG upload. Squarespace's resized JPEG copies were encoded at quality 85, its WebPs came closest to quality 85 of the settings we tried, and none of the 35 uploads wider than 2,500 pixels came back wider. At 1,000 pixels wide, Chrome's WebPs of JPG uploads weighed 24% less in total than the JPEG copies Squarespace sends browsers without WebP. Chrome's WebPs of PNG uploads were lossless and weighed more than twice as much as the PNG copies those browsers get, cut to 256 colours or fewer. GIFs went out as GIFs. What that means for your uploads is in the list near the end.

8 min read
Bar chart of eleven JPEGs from 3.4 MB to 27.3 MB. In every bar the picture fills almost the whole length; everything else, 0.06 to 10.27 percent of each file, is a thin orange strip at the end.

Why is my JPG file so large? What 11 real JPEGs are made of

The biggest JPG we opened was 27.3 MB: a 20-megapixel photo of the Milky Way, exported from Adobe Camera Raw. The picture itself was 99.56 percent of the file. Everything else (editing notes, camera data, a thumbnail, a colour profile) came to 0.44 percent. Ten more JPEGs, from phones, cameras, photo editors and an AI image model, told the same story: the picture was between 89.7 and 99.9 percent of every file. So if your JPG is too big, it most likely has more pixels than you need, or it was saved at a quality setting at or near 100. The steps to fix both are at the end.

7 min read
Three c2patool verdicts on a Google-signed Gemini JPEG: the 1,037,497-byte original is Trusted, a libjpeg-turbo jpegtran -copy all -optimize copy with the same pixels is Invalid (dataHash.mismatch), a cjpegli quality 90 copy has no claim.

Does compression remove Content Credentials? Two signed Gemini images through 13 tools

We took an image made by Nano Banana 2, one of Google's Gemini image models, and asked c2patool whether its Content Credentials hold. It answered "Trusted": a C2PA manifest signed by Google LLC, stating "Created by Google Generative AI.", with every hash matching. Then we ran that JPEG, and a PNG from the original Nano Banana, through 13 tools, WordPress 7.1.2 and Iminify among them, and asked again. Every file those tools wrote failed if it differed from its source by even a byte. Most tools dropped the manifest. Five kept a copy of it that no longer verified, in some cases without changing a single pixel. If a compressed file has to carry a working credential, something has to sign it again after the last byte changes, and that adds bytes of its own.

8 min read
A frame of Muybridge's galloping horse beside bars for its GIF and five fixes: 555 KB as it is, 562 KB after a lossless optimise, 228 KB as a lossy GIF, 154 KB as WebP at Smart, 72 KB as MP4 and 69 KB as WebP at Ultra.

Why is my GIF so big? What each fix did to four real GIFs

Eadweard Muybridge's galloping horse, as the GIF on Wikimedia Commons, is 15 frames of 300 by 200 pixels that play for a second and a half. It weighs 555 KB. Converted to an animated WebP at Iminify's Smart level, it came to 154 KB and scored 88 on SSIMULACRA 2, a quality measure on which 80 means an average viewer notices no difference side by side.

8 min read

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.