A catalogue card is a fixed amount of paper no matter how big the book is. A PNG text chunk works the same way, and that is the entire finding in this article.
A catalogue card is a fixed amount of paper no matter how big the book is. A PNG text chunk works the same way, and that is the entire finding in this article.
Six real files, measured. The parameters block adds exactly 740 bytes to a 166 KB thumbnail and exactly 740 bytes to a 1,059 KB portrait.
Everybody has an opinion about whether to keep generation metadata in the file. Almost nobody has measured what keeping it costs. So six real images went through a script this morning, saved twice each, once bare and once with a full A1111 style parameters block written in, and the difference was recorded to the byte.
The answer is more interesting than a number, because it is the same number six times.
The text written into each file is a realistic parameters string: a prompt, a full negative prompt, and the tail of settings that every UI appends. Steps, sampler, CFG, seed, size, model hash, model name, VAE, denoising strength, clip skip, hires upscaler, two LoRA hashes and a version string.
That last figure matters later. A parameters block is extremely compressible text, roughly 66 percent of its original size, because it is full of repeated field names and a fixed vocabulary.
Six images, all saved as PNG at compression level 6, once with no metadata and once with the block written as a standard tEXt chunk.
| Dimensions | PNG, bare | PNG with parameters | Delta | Delta as share |
|---|---|---|---|---|
| 1024 x 576 | 781,696 | 782,436 | 740 | 0.095% |
| 683 x 1024 | 1,058,988 | 1,059,728 | 740 | 0.070% |
| 336 x 336 | 166,173 | 166,913 | 740 | 0.445% |
| 683 x 1024 | 1,030,867 | 1,031,607 | 740 | 0.072% |
| 1024 x 341 | 462,846 | 463,586 | 740 | 0.160% |
| 800 x 562 | 687,913 | 688,653 | 740 | 0.108% |
Minimum 740. Maximum 740. Mean 740. Across the six files that is 0.106 percent of 4,188,483 bytes of image payload.
The flatness is the whole point and it follows directly from the format. A PNG tEXt chunk is stored uncompressed, and its overhead is fixed: four bytes of length, four bytes of chunk type, the keyword, one null separator, then four bytes of CRC. With the keyword parameters that is 23 bytes of structure around 717 bytes of text. Nothing about the image affects it.
A fixed cost against a variable payload is a percentage that moves entirely with the payload. On the 683 by 1024 portraits the metadata is 0.07 percent of the file and arguing about it is a waste of a morning. On the 336 by 336 thumbnail it is 0.445 percent, more than six times the share, for the identical text.
A gallery serving a 336 pixel preview of every image is paying that 740 bytes on the version of the file that gets requested most often and needs the metadata least. Nobody reads generation parameters off a thumbnail. They open the full image first.
PNG has a compressed text chunk, zTXt, which is the same idea with the payload deflated. Same file, same block, one flag changed:
| Chunk type | Added bytes | Versus tEXt |
|---|---|---|
| tEXt, uncompressed | 740 | baseline |
| zTXt, deflated | 499 | 241 bytes less, a 32.6 percent saving |
In Pillow it is one keyword argument on the same call, add_text("parameters", block, zip=True). Every PNG reader in the world handles zTXt, it has been in the specification since 1996, and the parameters remain fully readable afterwards. The information is not lost, it is just not stored as plain text you can find with a hex editor.
Across a hundred image gallery that is 72.3 KB of tEXt metadata dropping to about 48.7 KB. Which brings us to the honest part.
Seventy two kilobytes across a hundred images is nothing. It is a third of one of the images in the table above. If you are stripping metadata to save bandwidth, you are optimising the wrong end of the file by two full orders of magnitude, and the same six files make the case better than any argument:
| Change | Effect on those six files |
|---|---|
| Strip the parameters block | saves 0.106% of bytes |
| PNG to lossless WebP | drops to 70.9% of PNG size |
| PNG to WebP quality 90 | drops to 12.4% of PNG size |
The codec decision is worth roughly eight hundred times the metadata decision. Anybody removing parameters blocks for performance reasons while still serving PNG is picking up pennies in front of a truck.
Which leaves privacy as the only good reason to strip, and it is a good one. A parameters block names your checkpoint, your LoRAs and their hashes, your sampler, your seed and quite often a prompt you would not read out loud. That is a disclosure decision, not a file size decision, and it deserves to be made on its own terms rather than smuggled in under an optimisation argument.
Save the same image object twice through Pillow, once with no pnginfo and once with a PngInfo carrying your text, at a fixed compress_level, and subtract. Fixing the compression level matters: comparing a level 6 save against a level 9 save measures the encoder, not the metadata. Then run it again with zip=True for the zTXt number.
Do it on your own output rather than trusting these six files. The block length is the only input that changes the answer, and yours will be longer if you run a stack of LoRAs and shorter if you use a minimal UI. The structure of the finding will not change, because 23 bytes of chunk overhead is 23 bytes of chunk overhead on every image anybody has ever saved.