There is an image file, 1,918 bytes long, that decodes to a picture — and, on the way, computes the prime numbers up to 33,599. Decoding it takes 17.43 seconds of CPU time on an M5 Pro using the Rust JPEG XL decoder that is currently being shipped into Firefox and Chrome. The file is not a malicious binary exploiting a bug. It is a valid image, encoded within the rules of the specification, and the specification is expressive enough that a legitimate encoding can instruct the decoder to perform seventeen seconds of arithmetic per view. The people who found it call it the prime wall, and its size is the entire argument: 1,918 bytes of data, seventeen seconds of your machine's life, and the fuse is in the format.
The case against JPEG XL was written by Gianni Rosato, a compression engineer who works on AV1 and AVIF and who, by his own account, spent years endorsing JPEG XL — he backed it for Interop 2024 and counts its primary authors among his professional contacts. The post is a defection, not an attack, and its numbers are worth reading in order. On size-matched encodes of the same source image: JPEG 2,478,828 bytes; JPEG XL 2,599,428; AVIF 2,649,949; WebP 2,693,794. WebP is over ninety kilobytes larger than JPEG XL — and decodes more than ten times faster. The format's flagship feature, lossless recompression of existing JPEGs, saves roughly twenty percent — and costs roughly thirty-three percent longer decode time, which is the exact trade the web did not ask for. Its lossless advantage over lossless WebP is about eleven point nine percent, measured on a dataset of 157-megapixel photos, ten-megapixel illustrations, and twenty-seven-megapixel books — a workload that describes almost nothing on the public web, which is lossy by volume. And on lossy quality, where the web actually lives, the reference encoder loses to tuned AVIF encoders on every perceptual metric the field trusts.
Rosato's sharpest sentence is a general theorem disguised as an aside: there is no such thing as a codec benchmark, only an encoder benchmark. The format's theoretical ceiling is not what ships. What ships is an encoder, and the encoders that ship for JPEG XL do not clear the bar the web already has. But decode cost is a different matter, and that is where the argument turns structural. Decode cost is a property of the specification, because the specification decides what the bytes are allowed to ask of the decoder — and JPEG XL was designed, deliberately, to be everything to everyone: up to 4,096 channels, arbitrary bit depth, progressive decoding, patches, blending, frames used as residues, a coding toolbox so wide the spec runs to hundreds of pages. Every one of those features is an instruction the bytes can give to the decoder. Expressiveness is authority: the wider the spec, the more computation the data is allowed to command. The web's criterion for a format is not compression. It is boundedness — worst-case time per byte, on the median device, paid in battery — and the prime wall is that criterion measured: 1,918 bytes that buy seventeen seconds of a user's processor.
The pattern has a direct ancestor. The Billion Laughs attack was a one-kilobyte XML document whose nested entity definitions expanded exponentially — an entity defined as ten copies of itself, ten layers deep, a billion "lol" strings by the time the parser was done — and it brought down parsers for years before the fix arrived: parser limits, bounded expansion, a format that refused to let the data command unbounded work. The lesson encoded there is the one the codec debate is relitigating: a format that permits unbounded interpretation transfers unbounded cost from the data to the interpreter. Every feature in a spec is a potential bomb, and the only fix is at the level of the spec — you cannot defuse a bomb in the encoder when the fuse is in the specification.
There is a second boundary where the decoder has already failed the web once, and it explains the strangest detail of the current situation. In 2023, a heap buffer overflow in libwebp — CVE-2023-4863 — was exploited in the wild, in every Chromium browser, through nothing more than a crafted image file; the same year, Chrome's team cited attack surface when it declined to ship JPEG XL. A decoder is the one place where untrusted bytes from the entire internet meet native code, and the memory safety of that meeting point is not an engineering footnote; it is the product. Which is why the codec's current path back into browsers runs through a memory-safe reimplementation: the Rust decoder is not a performance improvement, it is the argument for shipability. The format's defenders are, in effect, conceding the case's central point — that a decoder is a security boundary first and a codec second — and responding by rebuilding the boundary in a safer language. The adoption debate stopped being about compression and became about whether the bytes can be trusted to ask for work.
The second number in the post concerns what a user sees first. Progressive decoding — the ability to show a usable low-fidelity image while the rest of the file is still arriving — is the property that most directly maps to perceived speed, and the measurements are stark: AVIF shows a recognizable image after roughly two to three percent of the file has arrived, while JPEG XL, in the browsers where it runs at all, gets its progressive support through a polyfill. On a slow link, that gap is the difference between a page that appears and a page that waits. The web's users do not experience compression ratios. They experience time-to-first-usable-image, and the format whose spec was built for archives keeps losing the race that happens in the first hundred milliseconds of a scroll.
And the post's closing recommendation names the principle the whole case reduces to: web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the web. Narrowly scoped is the load-bearing phrase. Scope is what a spec gives up to become safe — every feature removed is an instruction the bytes can no longer give, an attack the decoder no longer has to defend, a worst case the format no longer has to survive. A format designed to be everything to everyone is a format whose worst case is everything. The web's answer, arrived at twice now — with WebP's narrowness criticized as too narrow, and AVIF's container as too loose — keeps landing in the same place: the format that survives is the one whose specification is a contract about the work bytes may ask for, and whose bomb cannot be built at all.
None of this is a verdict against the format's engineering. It is a description of what the web actually pays for. The archive stores a file once and serves it forever; the web pays for it on every phone that scrolls past it, in battery and in milliseconds, and adversarial bytes are not a hypothetical — they are shipping, in browsers, right now. The web will adopt the format whose worst-case decode is cheap, whose spec cannot express a prime wall, and whose decoder is safe to point at the entire internet. The 1,918-byte bomb is the unit in which that decision is denominated, and every format that wants the web's bytes will have to prove, at the level of its specification, that its worst file is as harmless as its best.