Pangram verdict · v3.3
We believe that this document is a mix of AI-generated, and human-written content
AI likelihood · overall
MixedArticle text · 742 words · 3 segments analyzed
A while ago I wrote about storing two bytes inside my mouse's DPI register. It wasn't useful. It wasn't practical. But it did something unfortunate to my brain. Once you've successfully hidden data somewhere it doesn't belong, you start looking at everything as potential storage. A monitor is storage. A keyboard is storage. A BIOS splash screen is (maybe) storage. A favicon is storage. And yes, here we are. Every website has a favicon. It's that little icon in your browser tab. Usually you upload it once and then never think about it again. But. A favicon is just an image. An image is just pixels. And pixels are just bytes. So of course I wondered if I could store something inside one. The idea My first thought was steganography. Steganography is basically about hiding data in an image without making it obvious. You take a perfect normal photograph and modify a few bits so it secretly contains a message. The favicon itself (at least in my demo) doesn't need to look like an icon. It could become pure storage. Every pixel has red, green and blue values. That's three bytes. If I wanted to store text, I could just take the UTF-8 bytes of the text and write them directly into the RGB channels. The browser doesn't care what those bytes represent. To the browser they're colors. To me they're HTML. Building a favicon website I started with a tiny HTML payload: <h1>Website in a Favicon</h1> <p>Everything you're reading right now was decoded from favicon pixels.</p> The process is pretty straightforward. First I convert the HTML into bytes using TextEncoder. Then I prepend four bytes containing the payload length. The length header is important because the image itself may contain unused pixels at the end. If there's no length value, there's no way to know where the real payload stops. Once I have the byte array, I start filling pixels. The first byte becomes the red channel of the first pixel. The second byte becomes the green channel. The third byte becomes the blue channel. Then the next pixel. And the next. And the next… Eventually the entire HTML document exists as colored pixels. The resulting image looks like visual noise. Very small What surprised me most wasn't that it worked, to be honest.
It was how small the resulting image was. The payload ended up being 208 bytes. Adding the 4-byte header brings the total to 212 bytes. Since every pixel stores three bytes, I needed:212 bytes total71 pixelsA square image large enough to contain them The smallest square that works is 9x9 pixels. That's only 81 pixels. The final stats looked like this:Payload: 208 bytesImage size: 9x9 pixelsCapacity: 239 bytesUsed: 87% Somehow a whole little website (okayy, html with some styling) fits inside an image that's smaller than the usual favicon. Reading the website back out Storing data is only half the problem. The other half is getting it back. Browsers already have everything needed for this.The favicon gets loaded as image.The image gets drawn onto a canvas.The canvas API lets JavaScript read every pixel. Once I have the pixel data, I simply reverse the process.Read the RGB values.Reconstruct the byte array.Read the first four bytes to determine the payload length.Extract the payload.Decode the UTF-8 text. At that point I have the original HTML again. The browser read a website out of its own favicon. The important catch The favicon doesn't actually contain the whole website itself. It contains the content of a website. You still need a tiny bootstrap loader to decode the image. Without the JavaScript the favicon is just a PNG (which contains your website content). For showing this scenario the site includes a "Render Website" button. It reads the favicon, decodes the HTML, and replaces the page with the reconstructed content. Is this useful? No, of course not.
The amount of data you can store is tiny. The page needs JavaScript to bootstrap itself. There are dozens of better ways to distribute a small HTML document. But at the end its about testing the boundaries, right? A favicon feels like a very specific thing. It's supposed to be an icon. But at the end it can just be a PNG. And a PNG file is basically just bytes. And this is probably the smallest website I've built…
Here is the link to the site: https://www.timwehrle.de/labs/favicon-site/ And if you want to see how it works: https://github.com/timwehrle/favicon