What's the smallest file size for a 1 pixel image?


There are lots of new image compression formats out there. They excel at taking large, complex pictures and algorithmically reducing them to smaller file sizes. All of the comparisons I've seen show how good they are at squashing down big files.

I wanted to go the other way. How good are modern codecs at dealing with tiny files?

Using GIMP, I created an image which was a single white pixel, and saved it as a PNG. I then used Squoosh to convert it to a variety of modern formats using different encoding options. This is what I found:

FiletypeBytes
AVIF303
JPG155
BMP 1126
ICO 270
PNG 367
GIF 435
WEBP30
JXL24
QOI23

This is designed to be the "minimum viable viewable image". I loved Stoyan Stefanov's "Minimum viable no-image image src". That creates a 42 byte SVG with no image data in it - so I thought I'd see what happens if you make a displayable image.

Some important things to note:

  • Older image formats like BMP and GIF are smaller than newer formats like AVIF.
  • Some compression options make files larger in unexpected ways. The lossy WebP was larger than the lossless version.
  • Similarly, increasing the effort on an AVIF can also result in a larger filesize.
  • Neither JPEG XL nor QOI are supported in mainstream browsers yet.
  • AVIF has a rather long and complex header - that makes sense for large images, but bloats it for smaller ones.
  • Using Brotli, it is possible to further compress the AVIF (203 Bytes), JPG (69 Bytes), BMP (63 Bytes), and ICO (30 Bytes) files.
  • WebP is the smallest file if you still need a Spacer.gif!

Here's my challenge to you - can you do any better? What's the smallest filesize you can find for a viewable image?


  1. The BMP was created in ImageMagick and compressed with FileFormat.app
  2. The ICO was created with convert -size 1x1 canvas:white w.ico 
  3. See Evan Hahn's post about why this is the smallest PNG
  4. It is possible to go slightly smaller if you don't care about colour

Share this post on…

15 thoughts on “What's the smallest file size for a 1 pixel image?”

  1. says:

    i'd dig into the BMP formats a bit if i was going to take this seriously: it has different internal formats depending on colour depth and historical compatibility, and the ideal BMP must be smaller than the ideal ICO because the latter has a bigger overhead on what should be identical data that the BMP is nearly double the ICO suggests it's probably a 24-bit BMP optionally with transparency

    (a 1-bit RLE image should i think be 2 bytes without header, and you could possibly cheat and make a 0-sized image if you hand-crafted it)

    Reply
  2. says:

    @Edent QOI is cool because it provides the smallest image in this case, but also because you could hand-assemble it using a hex editor and the one-page spec (https://qoiformat.org/qoi-specification.pdf):

    Header: 3 * 4 bytes + 2 * 1 byte
    QOI_OP_DIFF: [insert the correct bit pattern here, I’m sleepy and a little bit confused about how it works]
    Stream end: 8 bytes

    Reply
  3. Terence posted a challenge today:

    Here’s my challenge to you - can you do any better? What’s the smallest filesize you can find for a viewable image?

    The Netpbm project comes with a bunch of file formats I often reach for when I want to generate images without a lot of code or external dependencies. They have binary and ASCII versions, here’s how to generate a plain text, 1×1 white image using the monochrome pbm format:

    1
    
    P1 1 1 0
    

    If you copy and paste that into your favorite text editor and save it as white-pixel.pbm you should get a file that weighs 8 bytes. Here’s what that looks like on my machine:

    A screenshot displaying a hex editor on the left and a plain white square image labeled white-pixel.pbm on the right. The text content in the hex editor reads P1 1 1 0.

    Reply
  4. says:

    @Edent You said, “Neither JPEG XL nor QOI are supported in mainstream browsers yet.” I believe Safari began supporting JPEG XL as of v.17.x, which was part of the recent major Apple OS updates.

    Reply
  5. says:

    @Edent I did exactly this, and it was a fun exercise. I also discovered that Brotli can “compress” the file to 23 (different) bytes at compression level 11, meaning there’s no overhead, which seems pretty unusual.

    Reply
  6. says:

    If you are willing to drop the 1px requirement the smallest possible JXL image is 12 bytes. It can skip some bits if the image is a multiple of 8 in both dimensions.

    For example, these 12 bytes (in xxd order) are a black 512 × 256 JPEG XL image.

    ff0a ff07 0883 040c 004b 2018
    Reply
  7. Ivan says:

    At such small sizes, the size of the file header becomes more heavy than the data itself. This is basically the showdown of complex file headers.

    The very minimum you'd need (assuming no compression, just raw data) is few bytes for image dimensions, followed by pixel data itself. Let's say you 'invent' a file format that assumes 24 bit rgb images, and has limits of 65535 pixels width * 65535 rows, that would be two 16 bit integers, followed by 3 byte pixel data (8 bits for each, red, green, and blue components of pixel).

    This is extremely bare bones, but still functional enough to serve a purpose of storing true color images.

    If you did some predefined dimensions file type, like .ico files of old, then you could use a single byte as an index into some standard predefined dimensions list (1x1, 4x4, 16x16, 32x32, 64x64...), and if you used basic rle compression you could reduce 24 bit white pixel data two bytes. That's 3 bytes in total. Again, completely bare bones.

    There are such file types in the wild, mostly the ones from 90-ties when such things mattered. Off the top of my head pbm comes to mind, tga is also quite basic...

    Reply
  8. says:

    @blog fun little experiment. From what I remember the smallest valid tif is something around 50 to 60 bytes.

    8 bytes header
    2 bytes ifd header
    8 bytes per ifd, I think you need five, witdh height, colour encoding, colour layout, and pointer to row pointers
    4 bytes of row pointer
    3 bytes of data

    One of the things I discovered when I was playing with tif files alot a few years back.

    (Numbers likely wrong, I wrote this from memory on a train)

Trackbacks and Pingbacks

What are your reckons?

All comments are moderated and may not be published immediately. Your email address will not be published.Allowed HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <p> <pre> <br> <img src="" alt="" title="" srcset="">

Discover more from Terence Eden’s Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading