canvas.toBlob hands Safari users a PNG labelled .webp

The callback signature cannot tell you which of two things you received. toBlob returns a Blob, and on the post's reading of the HTML spec an unsupported type is swapped for image/png ^[5], with neither a throw nor a null to mark the substitution ^[4]. The pixels are fine and the file is valid; the only field carrying the truth is blob.type ^[7]. Safari has decoded WebP since version 14 ^[3]. Encoding one through canvas has never been available there ^[2].

The guard in the post awaits convertToBlob, compares the returned type against the requested MIME, and throws a message that names the missing capability and points at the WebAssembly encoder ^[7]. That single comparison turns a silent wrong-file bug into an unsupported-browser error, which is a condition you can branch on.

The same shape shows up one layer down. libwebp will hit a byte budget directly: ask for 200 KB and the encoder converges on it, instead of re-encoding at a dozen qualities and bisecting ^[17]. Convergence happens through repeated entropy analysis, so at the default of a single pass there is nothing to converge across and target_size is dropped with no indication ^[18]. The post sets pass to 6 only when a budget is actually present, because passes cost real time ^[19]. Both bugs have one signature: a parameter is accepted, something else happens, and verification means inspecting the output rather than trusting the input ^[21].

The survey behind the opening claim is "every browser-based WebP converter I looked at" ^[1], which is a sample, not a census. Two conditions decide whether it reaches your code: you request a non-PNG type from canvas, and you derive the download filename from the format you asked for rather than from the blob you got back. If both hold and any of your traffic is Safari, the mislabeling is already shipping.

Leaving canvas costs a codec bundle, and the bundler configuration is where the post spends most of its six documented problems ^{[8] [22]}. The exclude and include lists in one Vite config read as contradictory until you have the test. jSquash's Emscripten glue gets rewritten by the dependency pre-bundler and then cannot resolve its sibling .wasm file, so it goes in exclude ^[10]. utif2 and libheif-js are CommonJS, and pre-bundling is the step that makes them importable at all, so they go in include ^[11]. What decides the side is whether the package loads a separate .wasm at runtime ^{[12] [20]}. Matching is per specifier, so @jsquash/webp does not cover @jsquash/webp/encode, and every subpath needs its own line ^[13].

The dev-server failure is the more expensive one to diagnose. Vite's startup scan walks the source graph and not dynamic imports inside workers ^[15], so the lazy HEIC load that keeps a JPEG user from pulling 2 MB ^[14] stays undeclared until someone converts one, at which point Vite re-optimizes and the page reload takes the queue with it ^[16]. The console message for that, 504 (Outdated Optimize Dep), is accurate and useless ^[16].

The assert is the cheap part. What it exposes is the price of an encoder you actually control: a WASM codec, plus a config that has to be told twice about the same dependency graph ^[9].