The author argues that JPEG's generic quantization tables are tuned for the 'average' photo and therefore optimal for none. By fitting a linear regression that predicts per-coefficient sensitivity for a specific image, they produce files that beat MozJPEG on both size and SSIM — proving there's still meaningful headroom inside the 1992 format itself.
The editorial frames JPEG's persistence as the point: WebP, AVIF, and JPEG XL have all been declared successors, yet baseline JPEG still dominates the public web because it has universal decoder support and no licensing risk. Every byte shaved off a JPEG multiplies across billions of requests without requiring any client-side upgrade — the same logic that justified MozJPEG in 2014.
Rather than only showcasing wins, the author walks through the math and explicitly documents the cases where per-image regression makes results worse. The editorial highlights this transparency as 'refreshing' — the technique isn't universally superior, and acknowledging that is what separates it from typical codec-benchmark cherry-picking.
By submitting the post and driving it to 285 points with 19 comments, the HN audience signaled that a clever reuse of a 34-year-old format still resonates with practitioners. The strong front-page reception suggests engineers care about pragmatic, deployable wins over exotic new codecs stuck in browser-support limbo.
A post titled *Regressive JPEGs* from maurycyz.com hit the front page of Hacker News with 285 points, and the premise is deceptively simple: use linear regression to compute a custom quantization table per image, and you can produce JPEGs meaningfully smaller than what `libjpeg-turbo` or MozJPEG will give you at the same visual quality. No new codec. No AI upscaler. Just a smarter use of the format that's been sitting on every phone and browser since 1992.
The core insight is that JPEG's quantization step — the part that actually throws information away — is driven by an 8×8 matrix of divisors, one per DCT coefficient. The values in that matrix are what encoders scale up or down when you ask for "quality 75" or "quality 90." Every mainstream encoder ships a generic quantization table tuned for the *average* photo, which means it's optimal for none of them. The author fits a regression that predicts, for a given image, which coefficients you can afford to quantize harder without visible degradation — and which ones you absolutely can't touch.
The result: files that beat MozJPEG (itself already a heavily-tuned fork of libjpeg) on both size and SSIM for the specific images tested. The post walks through the math, the failure modes, and — refreshingly — the cases where the approach makes things worse.
JPEG has been declared dead roughly every eighteen months since about 2010. WebP was going to kill it. Then AVIF. Then JPEG XL, before Chrome pulled support and left it in a weird open-source purgatory. And yet, in 2026, the vast majority of images served on the public web are still baseline JPEG, because it's the only format with truly universal decoder support and no licensing landmines.
That means every marginal byte you can shave off a JPEG multiplies across billions of requests without asking anyone to upgrade anything. This is the reason MozJPEG existed in the first place — Mozilla shipped it in 2014 with the pitch that a smarter encoder for the *same* format could deliver 5-15% savings with zero client-side change. Regressive JPEGs is the same bet, made harder.
The interesting subtext here is what it says about the ceiling of hand-tuned compression versus data-driven compression. The generic quantization table in libjpeg was designed by humans looking at test images in the early 90s. It's very good. It's also, by construction, a compromise. When you replace "the average photo" with "this specific photo," you recover exactly the slack that the compromise imposed — and that slack turns out to be non-trivial even after 30 years of encoder tuning.
The HN comments picked up on the obvious next question: if a linear regression can beat the generic table, what does a neural network do? The honest answer is that learned image compression has been beating JPEG on rate-distortion for years — see Google's HiFiC, or the whole line of work behind JPEG AI. The catch is decoder complexity. A learned codec needs the model on both ends. A regressive JPEG needs nothing on the decode side, because the custom quantization table ships *inside the file* — JPEG has always allowed this; nobody bothered to exploit it.
The other comment thread worth reading is the one arguing about SSIM as a quality metric. SSIM correlates poorly with human perception at high quality levels, and a compressor that optimizes for SSIM can find perverse solutions that score well and look worse. The author acknowledges this and shows uncropped comparison samples, which is the right move.
If you're serving images at scale, the practical question is whether to bolt this onto your image pipeline. The economics are straightforward: you spend CPU at encode time — once, per image — in exchange for lower bytes-served forever. For a CDN-fronted site with cache hit rates in the 90s, that math is almost always favorable. For a site that regenerates images per request, you'd want to benchmark.
The integration path isn't quite plug-and-play yet. MozJPEG has a stable C API and language bindings everywhere; this is a research-quality project. If you want the technique in production today, you're either wrapping the author's code or reimplementing the regression step on top of `libjpeg-turbo`'s custom-quant-table hooks. Neither is hard — the regression is a small linear system per image — but it's a weekend project, not an `npm install`.
The more interesting play, if you're in the image-infrastructure business, is to treat this as evidence that per-image encoder tuning has more headroom than the field assumed. Cloudflare, imgix, Cloudinary and the rest have all been pushing AVIF and format-negotiation as the answer. A cheaper answer for the JPEG long tail is right here. Someone will productize it within the year.
The deeper lesson is that mature formats aren't done being optimized just because the standard hasn't moved. JPEG has had a stable bitstream since 1992, and people are still finding double-digit savings in 2026 by being smarter about the encoder — which suggests the same is true of every other "solved" codec you rely on. Expect this technique to migrate into a MozJPEG-2 style fork, expect a neural-net variant that fits the quantization table with a tiny on-device model, and expect at least one CDN vendor to quietly ship it as a checkbox by the end of the year.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.