HN Debrief

I Stored a Website in a Favicon

  • Programming
  • Security
  • Privacy
  • Web Development

The post is a playful proof of concept. It packs a very small HTML payload into the pixels of a favicon, then uses client-side code to read those pixels back out and rebuild the page. The trick is not that favicons are a good place to ship web apps. It is that almost any browser feature can become storage if you are stubborn enough.

Treat this as a reminder that browsers expose a lot of odd storage and execution surfaces beyond cookies and local storage. If you work on web security, privacy, or browser-based products, favicon handling and cache behavior still deserve explicit threat modeling.

Discussion mood

Mostly amused and positive. People liked the project as a weird web hack, but many also said the chosen method was delightfully overengineered and quickly surfaced easier technical variants. The one serious note was discomfort about favicon-based tracking and cache abuse.

Key insights

  1. 01

    Polyglot files remove the separate loader

    Polyglot files push the idea further by making one blob valid as both a web page and an image, which cuts out the separate bootstrap step the post still needs. The linked demos show HTML that is also PNG, ZIP, and even PDF compatible, which reframes the favicon trick as one member of a much older family of file-format abuse and compression games.

    If you are designing filters, scanners, or upload pipelines, do not assume a file has one meaning because its extension or MIME type says so. Test your handling against polyglot cases, especially when browser rendering is involved.

      Attribution:
    • Retr0id #1
    • gildas #1
  2. 02

    Favicon caches are a real tracking surface

    Favicon storage is not just a novelty channel. It has already been used as a browser fingerprinting and supercookie mechanism because favicon caches can behave differently from normal web storage and may survive privacy boundaries users expect to hold. That turns an amusing encoding stunt into a reminder that “non-storage” browser features often become identifiers anyway.

    Include favicon requests and caches in your privacy reviews. If you build browser-facing products, verify how your stack behaves in private browsing, cross-site navigation, and tracker-blocking modes instead of assuming browser defaults are safe.

      Attribution:
    • sheept #1
    • ai_fry_ur_brain #1
    • schobi #1
  3. 03

    The browser already offers easier hiding places

    PNG text chunks, ICO multi-resolution payloads, and SVG markup all make this kind of embedding easier and roomier than raw pixel packing. That sharpens what the post is actually demonstrating. The interesting part is not efficient data storage. It is the self-imposed rule that the payload must live in visible pixel data rather than in the file format’s built-in metadata or markup features.

    When you evaluate a clever demo, separate the underlying platform capability from the author's chosen constraint. That helps you see both the practical options and the real novelty.

      Attribution:
    • Walf #1
    • weetii #1
    • peter-m80 #1
    • berkes #1
  4. 04

    Favicons could become a crude content stream

    Because browsers fetch favicons eagerly and cache them hard, one commenter suggested serving a sequence of dynamically generated icons and decoding them in order as a transport channel. The bandwidth would be awful, but the idea is notable because it turns a tiny decorative asset into a fetch path that might slip through systems built to inspect ordinary page content.

    When you think about blocked-content evasion or data exfiltration, include low-bandwidth asset channels in your model. Defenses that only inspect main document requests leave strange gaps.

      Attribution:
    • berkes #1
  5. 05

    This belongs to the demoscene tradition

    The closest cultural match is not application engineering. It is demoscene-style constraint programming, where the point is to make something work inside a ridiculous container. The reference to Inigo Quilez’s pixel-coded 256 byte intro makes the project easier to read. It is less about shipping value and more about proving that formats and tools can be bent far past their intended use.

    Judge hacks like this by what they reveal about platform flexibility, not by whether you would deploy them. They are often useful as test cases for parsers, caches, and browser assumptions.

      Attribution:
    • cfrs #1

Against the grain

  1. 01

    The impractical method is the whole point

    Pushing SVG or metadata as the “right” solution misses why the demo is fun. The payload living in actual pixel data is the challenge, and the Rube Goldberg aspect is the result people are supposed to enjoy. That framing matters because otherwise the project looks pointless instead of intentionally constrained.

    Do not overcorrect every experimental post into a production architecture review. Sometimes the value is in exposing assumptions by choosing the least convenient path.

      Attribution:
    • montebicyclelo #1
    • weetii #1
  2. 02

    The article style is not reliable AI evidence

    Several people pushed back on the confident claims that the post was LLM-written. The stronger case was that the short, blunt prose reflects a personal style, possibly shaped by writing for small screens or by a dislike of long sentences, and that detector tools and vibe checks are weak evidence on their own.

    If you are reviewing technical writing, focus on whether it communicates clearly and accurately. Guessing authorship from style alone is becoming a noisy and unhelpful habit.

      Attribution:
    • benhill70 #1
    • bstsb #1
    • weetii #1
    • stevenhuang #1
  3. 03

    Not every weird browser trick is interesting

    A few readers rejected the novelty outright. Their point was that the web already has many established ways to serialize pages into URLs, CSS, images, or other odd containers, so another storage stunt needs either a sharper technical payoff or a stronger aesthetic payoff to justify the attention.

    If you publish this kind of experiment, explain what constraint you are exploring and what new thing it teaches. Otherwise many readers will file it under gimmick and move on.

      Attribution:
    • titularcomment #1
    • brtkwr #1
    • soanvig #1

In plain english

fingerprinting ↩
Identifying or correlating a device or user by combining many small signals, even without a direct user ID.
ICO ↩
A Windows icon file format that can store multiple icon images at different sizes and color depths in one file.
LLM ↩
Large language model, a machine learning system trained to generate and analyze text, including source code.
PNG ↩
Portable Network Graphics, a common raster image format that supports lossless compression and optional metadata chunks.
supercookie ↩
A tracking identifier stored outside normal cookie controls so it can persist even after users clear ordinary cookies.
SVG ↩
Scalable Vector Graphics, an XML-based image format that describes shapes and text rather than storing pixels directly.

Reference links

Tracking and privacy references

Polyglot and format abuse demos

Related favicon experiments

  • Pong in a Favicon HN post
    Another recent example of abusing the favicon surface for a toy project.
  • Pong in a favicon
    Live demo of favicon-based interaction mentioned as a related experiment.
  • Favicon Doom
    Example showing Doom rendered in a favicon, used to answer whether games in favicons are possible.
  • faviconSnake
    Another game rendered through favicon updates, cited as proof the idea is workable.
  • favicon-bug repository
    Old demo of unbounded favicons that reportedly crashed some browsers.

Constraint programming and self-contained web pages

  • Real pixel coding by Inigo Quilez
    Demoscene-style reference for encoding a program through pixel data alone.
  • urlpages
    Project that stores a page in the URL rather than in a favicon.
  • serverless-architecture
    URL-only notepad quine cited as a related self-encoding web trick.
  • CSS without HTML
    Older example of making a browser render a page from an unexpected substrate.
  • web2img
    Related project for storing web content inside image-like containers.