The canvas spec tells browsers to answer an AVIF export request with a PNG

Call toBlob with a type the browser cannot encode and nothing fails. The callback fires, you get a Blob, and blob.type reads image/png where you asked for image/avif ^[1]. The dev.to post documenting this measured both entry points on Chrome 153, canvas.toBlob and OffscreenCanvas.convertToBlob, and both logged image/png ^[2]. Chromium has an open issue for it, 40848792, and neither Firefox nor Safari encodes AVIF from a canvas ^[3].

Support therefore has to be read off the output. The post's canEncode() makes a 1x1 canvas, asks for the mime type at quality 0.8, and resolves true only when blob.type comes back equal to the request ^[4]. WebP passes in Chromium browsers. AVIF passes nowhere today ^[5].

The mislabelled file is the application's doing. When download code builds a filename from the type it requested, the user gets a .avif name wrapped around PNG bytes ^[6]. Filewhisk, the author's set of browser-only image tools, checked blob.type before offering the download and showed a "not supported" message. Two pages were left promising a JPG and PNG conversion to AVIF they could not perform ^[7].

Chrome 85 added AVIF decoding, and that is where the belief came from. "Displaying a format and producing it are different features, and I had merged them in my head," the author wrote ^[8].

Server-side conversion was out. The author wrote that sending the image to a server was not an option because the site's promise to users is that "your files never leave your device" ^[15]. jSquash packages Squoosh's libavif encoder as @jsquash/avif under Apache-2.0 ^[9]. It ships in two builds. The faster one needs SharedArrayBuffer, so the page has to be cross-origin isolated with COOP and COEP, and those headers block cross-origin resources that do not opt in, which ad and analytics tags generally do not ^[10]. The author shipped the single-threaded build ^[10].

Going without a bundler cost one more detour. jSquash's encode.js imports a bare specifier from wasm-feature-detect to switch to the threaded build, and a bare specifier fails to load with no bundler and no import map, so the author skipped the wrapper and imported the compiled codec/enc/avif_enc.js, which loads its .wasm relative to import.meta.url ^[11]. The worker is served from /vendor/avif-2.1.1/ ^[16].

A 1600x719 photo encodes in about 1.3 to 1.7 seconds on the author's machine ^[12]. That is 1,150,400 pixels ^[1], so single-threaded throughput works out at roughly 0.7 to 0.9 megapixels per second ^[2]. On the main thread the page is frozen for the whole encode, so it runs in a module worker at defaults of quality 50 and speed 6 ^[12][13]. The RGBA pixels for that photo come to about 4.6 MB ^[3], and the page transfers the buffer to the worker instead of copying it ^[14].

For those seconds to mean anything on your site you need a comparable single core, the same pixel count, and the same settings, since speed 6 is a middle setting and quality 50 is not lossless ^[13]. The post does not identify the machine.