I love the absurd verbosity of that reference svg:

User: Hello, browser, I'd like to create an svg object.

Browser: Now, hold on just one second. Is this the zeroth time you'd like to instantiate a custom xml object that you decided to name with the three letters 's', 'v', and 'g'? Or is this the 8,387,245,123rd time you'd like to instantiate a scalable vector graphics object?

User: sigh

Browser: OMG guess what? Thanks to the magic of universal resource locators and XML namespaces, I am able to parse the answer directly from the image data you sent me! Lemme check. Yup! The image itself holds the answer! Aren't computers fascinating?

User: sigh

Browser: Now I can state unambiguously that this is indeed the 8,387,245,123rd you want me to display an svg image in a web page. Glad we got that resolved!

User: click

Browser: Oops, relayout means you ended up clicking on an ad. Sorry, no takebacks.

The smallest 1x1 BMP file is 30 bytes, which has the advantage of still being displayable in my browsers.

Here's a 1x1 red pixel: https://raw.githubusercontent.com/mathiasbynens/small/master...

Check out the rest of the repo! This author, seemingly named Mathias Bynens, got interested in the smallest possible file in various formats.

https://github.com/mathiasbynens/small/

He's a pretty well known v8 engineer btw.

what a madman

i was impressed back then on his repo of bigint polyfill

I was hoping this would involve a hex editor and some neat tricks. Here's a one pixel PBM image in 9 bytes:

  P1
  1 1
  0

EDIT: I see there's a comment section already there with lots of interesting suggestions.

PNM formats are the best. Back in the day I wrote a lot of code to generate images thanks to its simple ASCII and binary output formats. That was back before graphics libraries were common, when generating an XBM was difficult and we were still worried about the GIF patent.

Hey, that was my first thought, too:) That format (family) has to be my favorite way to write picture files, even without bothering with an actual library.

I still really like QOI and love that their whole format specs fit on one sheet of paper (https://qoiformat.org/qoi-specification.pdf) while still delivering quite ok results.

Someone should go and update https://commons.wikimedia.org/wiki/File:Spacer.gif, which apparently is at least five bytes larger than needed: http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ev...

JPEG XL is unique in that the smallest possible file is not 1 by 1 but 8 by 8 due to the header encoding [1].

[1] https://twitter.com/jonsneyers/status/1381894108067868672

Here he writes https://twitter.com/jonsneyers/status/1378055527771602945

> a single pixel jxl image is 19 to 20 bytes depending on the color

Aww, I was hoping for some hand-tuning and spec lawyering to make the smallest possible images, not just looking the outputs of one random tool

Please feel free to write this blog post.

With Farbfeld, it's possible to further reduce the size of image data to be 24 bytes, or 16 if you're ok with your image not being displayable

    Magic Number: 66 61 72 62 66 65 6c 64 (identifies the file as a Farbfeld image)
    Width (in bytes): 00 00 00 01 (specifies the image width)
    Height (in bytes): 00 00 00 01 (specifies the image height)
    First Pixel Data: ff ff ff ff ff ff ff ff (represents the color data for the first pixel)

I went down this rabbit hole about 15 years ago, I ended up hand-rolling a transparent .gif which I think was 15 bytes? Small enough that we inlined it as cdata data urls. (Is that still a thing in HTML? It’s been so long…)

You can do that kind of thing in html today.

I use this embedded SVG for the logo on a page:

<img id="logo" src='data:image/svg+xml;utf8,%3Csvg%20width%3D%22100%25%22%20height%3D%22100%25%22%20viewBox%3D%220%200%2054%2050%22%20version%3D%221

I think I recall using a base64 encoded png at one point for a different project in the same way.

Minimizing bytes was not the reason for this. It was to tidy up the directory listing as this html was used as a self contained local file. I didn’t want a separate logo file hanging around and risk getting lost.

That's feasible in XHTML, but it don't think it's in the html5 spec.

Instead, you can use a data URL, though you'll be wasting bytes specifying the mime type and base64 encoding the rest.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...

That’s the one! Data URL! Thanks. :)

The primary way we used it was as the body of a tracking gif, returned as binary. But we also used it as a spacer here and there inline in HTML using the data URI. When embedding in HTML the file size is mostly relevant for brevity.

Wow, that takes me way back.

For some reason "CDATA" is ringing a bell and I don't know why. Was that a thing way back when?

EDIT: oh right, it was an XML/XHTML comment thing.

Not comments. Character escaping. (i.e., raw Character DATA)

It's apparently 46 bytes for TIFF: https://stackoverflow.com/questions/42787235/smallest-possib...

    echo -n 'P5 1 1 1  ' > a.pgm

10 bytes?

Pretty sure it was possible to get a GIF to 2x bytes.