Bitruvius Imagery & 3D Suite / TurboWebP Drop-in for libwebp Shipping · Private Beta

Same WebP. None of libwebp's memory risk. And 2.9× faster to write.

In 2023 a flaw in libwebp, the library behind almost every WebP image, was exploited in the wild (CVE-2023-4863) and forced emergency updates to browsers and the many apps that bundle it. TurboWebP is a memory-safe replacement: the same files, the same API, and that class of bug removed rather than patched.

Swaps in for libwebp 1.6.0 with no code changes. Byte-identical output on Intel, Apple silicon and in the browser.

2.9×

faster to write, both at defaults

For 2.9% more bytes. Geospatial 256-pixel tiles.

4.5×

faster at matched maximum effort

For 4.4% more bytes. Same on Intel and Apple silicon.

47 of 64

decode cells faster than libwebp

Pooled across both machines. About 20% faster on large tiles.

Memory-safe

the CVE-2023-4863 risk class, removed

Not just the known bugs patched: the class of bug they belong to.

Every speed figure is shown with the extra file size it costs, at the setting it was measured at.

The 60-second version

Nearly every WebP image runs through one library. In 2023, attackers exploited it.

The format

WebP

Google's image format for the web, apps and map tiles: smaller than PNG and JPEG, lossless or lossy, with transparency.

The incumbent

libwebp

Google's C library, inside browsers, image pipelines and countless apps. Nearly every WebP file is written and read by it.

The 2023 bug

One image could take over a computer

A single crafted image could let an attacker run code on the machine that opened it. It was used in real attacks before the patch shipped. Patches fix one bug; the class remains.

The fix

A memory-safe drop-in

TurboWebP reads and writes the same files through the same interface, so it swaps in for libwebp without code changes, and it is faster while it does.

Watch it

Race it yourself, in this tab.

TurboWebP against libwebp (Google's own C decoder, compiled to WebAssembly), decoding the same lossless bytes in your browser. Both sandboxed, apples to apples, clocked on your machine.

Image Codec Race: TurboWebP vs libwebp · live in your browser open full screen ↗

loading demo…

What it means for the bill

Less risk, less compute, no migration.

A safer library usually costs speed or a rewrite. This one costs neither.

3.4 hours

for a job that used to take 10

Encoding tiles at both libraries' defaults, for 2.9% more bytes.

0 lines

of your code to change

It replaces libwebp where your software already loads it.

0 differences

between CPUs, in 800 files

The same output on Intel, Apple silicon and in the browser, so caches and dedup keys stay stable. libwebp does not offer this.

Illustrative, from the measured defaults figure. A pilot measures yours.

Encode

Faster at every tile size. On both architectures.

Lossless encode at quality=100 vs libwebp's highest-effort lossless setting (method=6). 400-sample real-world geospatial / EO corpus, n=100 per tile size, both encoders run at maximum effort. Output passes a 100/100 libwebp round-trip pixel-equality gate.

Encode speedup vs libwebp m=6

Mac NEON (Apple M3 Max) Win AVX2 (Intel Core Ultra 9) — — 1× parity with libwebp

Hosts: Apple Silicon (NEON) and Intel (AVX2). Output bytes are byte-identical across the two architectures on every sample, verified by a per-sample byte diff (0 differences across 800 samples = 400 apex + 400 defaults).

Wins across every workload we tested.

WebP encoding profiles look very different across imagery types. TurboWebP wins on all four, and is particularly dominant on the kinds of single-band imagery (SAR coherence quicklooks, AI inference masks) that the libwebp fast paths weren't tuned for.

Encode speedup by image type

Encode speedup vs libwebp m=6 — — 1× parity

Mac NEON, 256² tiles, lossless q=100 vs libwebp m=6. Size shows output bytes vs libwebp; smaller is better. At 512² and 2048², SAR quicklooks actually produce fewer bytes than libwebp's apex (0.993× and 0.996×). Win AVX2 ratios match within ~10% per cell; cross-arch output is byte-identical.

Pick your trade

One dial. Speed at one end, size at the other.

Most comparisons pick the operating point that flatters the winner. Here is the whole curve, measured against libwebp at its default on its own 131-file test corpus: the content its heuristics were tuned on, not ours.

Setting	Encode time	Output size	What it is for
method 0-2 (fast)	0.18×	1.072×	Ingest and thumbnailing, where throughput is the product
method 3-4 (default)	0.22×	1.063×	The shipping default: most of the speed, half the size gap
method 5	0.64×	1.046×	Archival writes that still have to keep up with libwebp
method 6 (max)	1.33×	1.027×	Cold storage, where bytes cost more than seconds

Lossless, 131 files, geomean of per-file ratios against libwebp 1.6.0 at method 4 (its default). Lower is better in both columns. On geospatial imagery the same default lands at 1.020-1.029× size and 0.343-0.602× time across 256² to 2048² tiles, n=100 per size.

Decode

Decode the same files. Get there ~20% faster.

The libwebp lossy decode path has been frozen at SSE2/SSE4.1 since ~2012; AVX2 only landed for the lossless path in libwebp 1.6.0. TurboWebP's decoder is AVX2/NEON/SIMD128 end-to-end. Decoded RGBA bytes are byte-identical to libwebp on every input.

Decode speedup vs libwebp 1.6.0 · Win AVX2

TurboWebP decode speedup Faster than libwebp — — 1× parity

Win AVX2 pooled decode_ratio (turbowebp / libwebp; lower is faster) across the 400-sample corpus, producer = libwebp m=6. 27 of 32 cells overall are faster than libwebp 1.5.0; the remaining 5 sit at 256² where fixed per-image setup costs dominate the small workload.

Drops into the pipeline

A library swap. Not a migration.

Memory-safe

The decoder's trust boundary is written in memory-safe code with no escape hatches, so CVE-2023-4863-class memory bugs are structurally impossible there.

Drop-in

A replacement library exports libwebp's C interface. Load it in libwebp's place (LD_PRELOAD, DYLD_INSERT_LIBRARIES or a DLL swap) with no host code changes.

Bit-exact

131/131 of libwebp's own test corpus decoded bit-exact, 800/800 geospatial round-trips, and the WebP RIFF container unchanged.

For the engineers

- 4.5× faster encode at 256-tile across both ISAs (4.5× Mac NEON, 4.5× Win AVX2). Even at 2048-tile the gap holds at 1.27-1.49×.
- 27 of 32 decode cells faster on Win AVX2 (20% pooled faster at 2048). 20 of 32 on Mac NEON. 47 of 64 cross-host.
- Three effort settings, not one. Against libwebp's own default on geospatial imagery, ours writes 2.0-2.9% larger at 1.7-2.9× its speed. On libwebp's own test corpus, method 5 writes 4.6% larger and still finishes in two-thirds of libwebp's time.
- VP8L lossless: bit-exact decode of every file in libwebp's own test corpus (131/131), plus 800/800 round-trip on the 400-sample geospatial corpus across both producers.
- And the other direction: all 131 files of libwebp's corpus, re-encoded by TurboWebP, decode back through libwebp to the same image, alpha exact everywhere.
- VP8 lossy: bit-exact decode. At matched quality on libwebp's own corpus our encoder writes 1.03× the bytes in 0.77× the time, at 35.7 dB against libwebp's 33.5 dB: the extra 3% buys 2.1 dB.
- Two cells BEAT libwebp m=6 on size: sar_csi 512 (0.993×) and sar_csi 2048 (0.996×).
- Your fourth band survives. Lossless WebP may discard the RGB under fully transparent pixels, libwebp's default and correct when alpha is opacity. On NAIP RGBN band 4 is near-infrared, so a NIR value of 0 would read as transparent and throw away the visible bands beneath it. Set exact and nothing is discarded; opaque tiles encode to the identical bytes either way, so it costs nothing to leave on.
- Byte-identical encoder output across NEON / AVX2 / WASM SIMD128, with SVE2 and AVX-512 planned for future releases. libwebp does not offer this.
- ISAs: AVX2 (x86_64), NEON (ARM64), WASM SIMD128 (browser), scalar fallback.

How this was measured

Encode: a 400-sample real-world geospatial / EO corpus, n=100 per tile size from 256² to 2048², lossless. "Maximum effort" is quality=100 against libwebp method=6; "defaults" is each library's default. Every output passes a libwebp round-trip pixel-equality gate.
Hosts: Apple Silicon (NEON) and Intel (AVX2); output bytes are identical across the two.
Effort tiers: libwebp's own 131-file test corpus, lossless, against libwebp 1.6.0 at method 4, geomean of per-file ratios.
Decode: Win AVX2 pooled across the geospatial corpus, files produced by libwebp at method 6; the cell counts compare against libwebp 1.5.0.
The live race decodes in your browser against Google's published libwebp WebAssembly build, so its numbers are yours, not ours.

Swap it into one pipeline.

A pilot runs both libraries on your own tiles, on your own machine: same files in, same WebP out. You keep the numbers.

See pricing

TurboWebP is licensed through the Bitruvius Developer Hub and ships as compiled binaries.

WebP and libwebp are products of Google LLC. References here identify the products and formats being compared; no affiliation, sponsorship, or endorsement is implied. libwebp is published by Google under a BSD-3-Clause license. The WebP container format is openly specified and freely usable. TurboWebP is an independent implementation of the WebP format, compatible with the libwebp ABI. CVE-2023-4863 is cited from the public CVE record. The live demo runs Google's unmodified libwebp decoder under its BSD-3-Clause license. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.