Biggest image in the smallest space 2011-12-03

Updated 2015-09-03

Updated 2016-12-03

Updated 2017-09-10

Updated 2017-11-15

Updated 2019-03-21

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

Content-Encoding: gzip

An earlier version of this page said to use Transfer-Encoding: gzip (as opposed to Content-Encoding ), but that probably won't work because an HTTP client must have opt in to a transfer coding by sending a TE header. Clients sending TE: gzip is uncommon compared to Accept-Encoding: gzip , which enables the server to send Content-Encoding: gzip .

Related reading:

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)