What’s the biggest pixel size of a PNG image in the smallest number of bytes? I wanted to try to create an image that could be downloaded but whose pixel buffer would be too big to store in the RAM of a PC. Here is a PNG image of 6,132,534 bytes (5.8 MB) and 225,000 × 225,000 pixels (50.625 gigapixels), which, if uncompressed and represented as a pixel buffer of 3 bytes per pixel, takes about 141.4 GB.

The PNG file is further bzip2-compressed to avoid abuse by people hot-linking it in img elements. The bzip2 compression doesn’t have anything to do with the high compression ratio in the PNG.

spark.png.bz2 (420 bytes)

The program used to make it: deflate.py.

bzr get https://www.bamsoftware.com/bzr/deflate

PNG uses DEFLATE compression in a zlib wrapper. DEFLATE can asymptotically approach a compression ratio of 1032:1: each pair of bits can represent 258 zero bytes, and then there’s some constant overhead for headers and such.

The image is almost entirely zeroes, with a secret message in the center. We gain an extra factor of 8 pixels by using a 1-bit colorspace. Even with this maximum compression, the PNG file is basically a long string of zero bytes. bzip2 has a run-length preprocessing step that crunches these megabytes into a few hundred bytes.

Things to try:

Upload as your profile picture to some online service, try to crash their image processing scripts.
Set as your web site’s favicon; try to crash browsers that don’t check the size.

Unfortunately the ratio of 1032:1 is really the best you can do. If you want an image with ten times the pixels, the PNG file has to be ten times the size. The above image is already close to the theoretical maximum (the extra divisor of 8 is because there are 8 pixels per uncompressed byte in the 1-bit colorspace):

>>> 225000.*225000/8/6132534
1031.893993575902

There’s a constant cost of 10⁹/1032/8 ≈ 121124 bytes per gigapixel. But if you are serving (or uploading) the image over HTTP, there’s another trick you can apply. Precompress the file and send it with Content-Encoding: gzip to gain another factor of 1032 (gzip also uses DEFLATE) and a communication cost approaching ≈118 bytes per gigapixel. This is like a two-layer recursive zip bomb, except that both decompression steps are side effects of normal processing. Going one step further, you could embed the PNG as an image in an ODF or OOXML document, both of which use a zip container (i.e., DEFLATE). You could get a compression ratio of about 1 billion: 1000× from PNG, 1000× from the document container, and 1000× from HTTP.

Related reading:

Defending Libpng Applications Against Decompression Bombs
How to defend your website with ZIP bombs (uses the HTTP Content-Encoding technique)
The tiniest GIF ever
The JPEG XL image format has demo potential
A better zip bomb, even trickier hacks with DEFLATE
The world's smallest PNG

What about the opposite question, the largest encoding of a 1 × 1 image? It’s not very interesting, because there are various ways of increasing the file size without affecting the image. For one thing, you can just stuff in a lot of text or other ancillary (non-image) chunks. But keeping in the spirit of DEFLATE, you can also use an unlimited number of empty non-compressed blocks in an IDAT chunk. Each non-compressed block with LEN=0 takes up 5 bytes: \x00\x00\x00\xff\xff. Following that strategy, here’s the 100 MB transparent tracking pixel you’ve always dreamed of:

splat.png.bz2 (4,733 bytes)

WebP

Anthony Fleming offers a 28-byte lossless WebP image that has the maximum allowable dimensions of 16,384 × 16,384 pixels. Its entire contents:

5249 4646 1400 0000 5745 4250 5650 384c  RIFF....WEBPVP8L
0800 0000 2fff ffff 1f88 8808            ..../.......

Here is a brief overview of the structure:

52 49 46 46 ("RIFF"): Required header.
14 00 00 00 (20): Little-endian length of the remainder of the file.
57 45 42 50 ("WEBP"): Required header.
56 50 38 4c ("VP8L"): Required header.
08 00 00 00 (8): Little-endian length of the remainder of the lossless stream.
2f: Required header.
ff ff ff 1f: image_width = 0x3fff + 1, image_height = 0x3fff + 1, alpha_is_used = 1, version_number = 0b000
88 8808: The remaining bytes specify no transforms, no color cache, a meta-prefix of 0, and then 5 1-symbol prefix codes. Because all prefix codes have a length of 0, no bits are required to encode an endless stream of 0 bits that fill in the image data.