I benchmarked AVIF vs WebP on real images, and the "best" format flipped depending on what I compressed

Filo Tool — Thu, 03 Sep 2026 10:34:15 GMT

Every "best image format 2026" article says the same thing: AVIF wins, WebP is second, JPEG and PNG are legacy. I believed that too, until I ran the same encoder at the same settings against two different image types and got opposite winners.

Same quality setting, same encoder. Opposite results.

I compressed a photorealistic image and a transparent graphic through JPG, PNG, WebP, and AVIF, all at quality 80, same encoder, same run. Here's what came back:

On the photograph (3.35MB source): WebP came out at 342KB. AVIF came out at 537KB — 57% larger than WebP, for a format that's supposed to be the efficient one.

On the transparent graphic (54KB source): AVIF won cleanly at 18.6KB. WebP trailed at 29KB. PNG saved as PNG actually came back larger than the original — +13.6%.

Same two formats. Same encoder. Same quality target. The ranking inverted completely depending on what was inside the file.

Why "just use AVIF" is bad advice

The instinct after seeing AVIF's reputation is to default to it everywhere. But AVIF's compression strategy is tuned for smooth photographic detail — it's genuinely excellent there in the general case, but it's not free computation, and on a photo where WebP's simpler model already gets close to optimal, AVIF's extra complexity can cost more than it saves. There's no universal winner. The right format depends on what's actually in the pixels.

The trap hiding inside the numbers

Here's the part that would have fooled me if I hadn't looked closer. On the transparent graphic, JPG actually beat WebP on file size (27.7KB vs 29KB). If you only looked at the number, JPG would look like the winner.

It isn't. JPG has no alpha channel. To "win" that comparison, it silently flattened the transparency onto a white background and destroyed the one property that graphic needed. A format that can't carry your actual requirement isn't a smaller version of the same image — it's a different, broken image that happens to compress well.

Smaller isn't better if the format threw away the thing you needed.

The format you can't rely on

There's a practical wrinkle with AVIF specifically that benchmark tables never show: browser support for encoding AVIF client-side depends on the browser's own native decoder, and that availability varies by browser version. In other words, the format that won the transparent-image test above is also the one most likely to be silently unavailable depending on who's opening your file. And animation is a harder wall entirely — still-image codecs only ever keep the first frame.

So even when AVIF wins on paper, it's not always the safe default in practice.

What I actually do now

Pick the format for what's in the image, not for its reputation:

Photos and complex gradients: WebP is usually the safer default — strong compression, broad support, and it doesn't lose to AVIF by nearly as much as AVIF sometimes loses to it.

Screenshots, UI, flat graphics, anything with transparency: worth testing AVIF specifically, since this is where it actually pulls ahead — but verify support if it needs to render everywhere.

Anything that needs to work absolutely everywhere with zero surprises: JPG (no transparency) or PNG (transparency, no compression guarantee) remain the boring, reliable choices for a reason.

The honest caveat

These specific percentages came from two fixtures I built for this test, not a universal law — the direction of the finding (rankings aren't stable across image types) generalizes; the exact numbers won't. Test your own asset before assuming either format is the "right" one.

If you want to check this yourself

I built a format comparison tool that runs these numbers against real images, and an image converter if you just want to convert a file — both run entirely in the browser, nothing uploaded. I'd be curious whether this holds on assets very different from mine.

Why "black box" PDF redaction almost never actually works

Filo Tool — Thu, 03 Sep 2026 06:56:11 GMT

I built a PDF redaction tool, and the thing that surprised me most wasn't how to draw a black box over text. It was how many "redaction" tools out there stop right at the drawing part — and ship it as if that's the same thing as actually removing the information. It isn't. And once you understand why, you'll never trust a black box on a PDF again. The problem with covering text Most online PDF editors "redact" by drawing a rectangle over the text you want hidden. Visually, it looks gone. But the original text is often still sitting in the PDF's data layer, underneath the box — selectable, copy-pasteable, and extractable with a script in seconds. The box is cosmetic. The data isn't touched. I didn't want to ship that. So the redaction tool I built doesn't draw over anything — it rebuilds the page. What actually happens to the file When you mark an area for redaction, the tool doesn't hide it. It re-renders that entire page as a flattened image — at 1.75x scale in Standard mode, 2.5x in High — and re-encodes it as a JPEG before embedding it back into the PDF at the original page dimensions. The rebuilt page has no text layer, no annotations, no form fields, no links. There's nothing left to extract, because there's nothing left that's text. The tradeoff is real, and I don't pretend otherwise: you lose selectability and the page gets a bit heavier. But you gain something almost no competing tool offers — actual, structural certainty that the information is gone. The part I'm most proud of: it checks its own work Before the tool ever lets you download a file, it re-reads its own output and verifies it. If the PDF signature is malformed, if the page count changed, if any extractable text remains on a page you marked for redaction, or if any annotation survived — it throws an error instead of handing you a file. You get told something went wrong. You don't get a silently broken redaction. That's the one thing I haven't found on a competing "redact your PDF online" page: a tool that proves its own result before trusting you with it. Where the real risk actually is Here's the honest limitation. The verification only checks pages you explicitly marked. If you forget to mark a page — miss a signature block on page 12, say — that page gets copied through untouched, text layer intact, and the built-in check has nothing to say about it because it was never told to look. The failure mode isn't "the redaction gets reversed." It's "you never told the tool to redact it in the first place." That's a much more common, much more human mistake, and it's worth knowing before you rely on any redaction tool, mine included. Why blur and pixelation aren't redaction either A quick related note, because I see this misunderstanding constantly: blurring or pixelating a sensitive value — a license plate, a phone number — feels like redaction, but it usually isn't. Pixelation is a deterministic transformation. If the original value comes from a small, guessable set (a 10-digit phone number, a plate format), you can pixelate every candidate value the same way and compare block patterns until one matches. You're not un-blurring the image — you're brute-forcing it. The pixels are genuinely destroyed; the exposure comes from a different angle entirely. If something needs to be irrecoverable, it needs the full rebuild-and-verify treatment, not a filter. If you want to try it The tool is free, runs entirely in your browser (nothing is uploaded, ever), and the redaction tool specifically is at filotool.com/redact-pdf. I'd genuinely like to know if this changes how you think about redaction tools you've used before — I learn a lot from what breaks people's expectations.

Filotool

I benchmarked AVIF vs WebP on real images, and the "best" format flipped depending on what I compressed

Why "black box" PDF redaction almost never actually works