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:39:24 +0000

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

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:36:20 +0000

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

Join The Writer's Circle event
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.

DEV Community: Filo Tool

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