Measured data

In-browser codec benchmarks

Every conversion on convert.now runs on your device, which raises a fair question: how fast is that, really? These are the numbers from our own harness, including the results that do not flatter us.

Headline result

The clear win is JPEG. The in-house jpegli build encodes roughly 8× faster than the mozjpeg baseline and produces files about 29% smaller at the same quality setting (q80). AVIF currently goes the other way — the rav1e encoder is both slower and larger than the baseline on an unmatched-quality comparison, and that needs fixing before it is a fair fight.

Results

Encode and decode times by codec

Median encode and decode times and output sizes for each WebAssembly codec, measured on a 512×512 image.
CodecOperationMedian timeOutput size
JPEG (jpegli)encode q804.5 ms30.3 KB
JPEG (jpegli)decode4.7 ms—
WebP (libwebp)encode q8048.8 ms56.6 KB
WebP (libwebp)decode5.6 ms—
AVIF (rav1e)encode q50, speed 8373.6 ms25.2 KB
PNGencode2.5 ms740.2 KB
OxiPNGoptimise level 2114.7 ms493.9 KB
Resize512→256, Lanczos331.8 ms—

512×512 RGBA synthetic photographic image. Median of 3 runs; AVIF encode and OxiPNG are single runs (both are slow enough that repeat runs cost more than they clarify).

Head to head

Our codecs vs the jSquash baseline

jSquash is the codec family convert.now still ships as a fallback, so it is the honest thing to measure against. Run in Headless Chrome on 2026-05-29, on the same image at matched quality settings.

convert.now’s in-house codecs compared with the jSquash baseline on time and output size.
OperationjSquashconvert.nowTimeSize
JPEG q80 encode40 ms42.5 KB5 ms30.3 KB-87%-29%
WebP q80 encode230 ms58.3 KB48 ms58.3 KB+60%same
AVIF q50 encode3323 ms13.0 KB379 ms25.2 KB+17%+94%
PNG + OxiPNG level 24161 ms521.8 KB132 ms521.8 KB-18%same
  1. 2Both engines use the same libwebp build, which is why the output sizes match exactly. The time difference is bindings overhead, not compression.
  2. 3Not a fair contest yet. The quality scales are not equivalent — rav1e q50 is not aom q50 — and rav1e is tuned for encode speed. A real comparison needs matched perceptual quality (SSIMULACRA2) and speed tuning. On this unmatched basis the baseline wins on both axes.
  3. 4Both engines run OxiPNG, so the output is byte-identical. The difference is pipeline overhead.

Method

How these were measured

Runner
Vitest bench, Node with the WebAssembly codecs loaded in-process
Input
512×512 RGBA synthetic photographic image
Sampling
Median of 3 runs; AVIF encode and OxiPNG are single runs (both are slow enough that repeat runs cost more than they clarify)
Baseline run
Headless Chrome, 2026-05-29. Same 512×512 image, matched quality settings.
Known limitation
The harness does not record the host machine's CPU, so absolute times are not portable between machines. The ratios between engines are the meaningful figure here, not the milliseconds.

FAQ

Browser codec performance: common questions

Fast enough that the upload step, not the conversion, is what makes server-based converters feel slow. On a 512×512 image, the WebAssembly codecs convert.now ships encode JPEG in about 4.5ms, WebP in about 49ms, and PNG in about 2.5ms. AVIF is the outlier at roughly 374ms, because AV1 intra-frame encoding is genuinely expensive work. Larger images scale roughly with pixel count.

Last updated

Quote these figures freely — attribution to convert.now/benchmarks is appreciated. If you reproduce them and get materially different ratios, we would like to know.