canvas.toBlob hands you a PNG and calls it WebP: check blob.type, not the user agent

The substitution survives every guard a careful person already writes. The callback fires, the blob is not null, and its size looks plausible ^[5]. Nothing in the API reports the swap, because the specification requires the fallback and says nothing about disclosing it: no exception, no warning, no second argument ^[2]. The single witness is `blob.type`, which on iOS below 16.4 reads `image/png` after you asked for `image/webp` ^[3].

There is an accident of history worth noting here. `toDataURL` falls back identically, but the string it returns opens with `data:image/png;base64,`, so the mismatch is readable without tooling ^[4]. The binary path is the quiet one.

The measured numbers are where this stops being theoretical. On desktop Chromium, six requested types produced two real encodes: WebP at 564 bytes and JPEG at 796 ^[9]. AVIF, HEIC, TIFF and GIF each came back as `image/png` at 95 bytes, and those four blobs were byte-for-byte identical, being the same 2x2 PNG four times over ^[9][10]. Two thirds of the requested list was mislabelled ^[15]. A pipeline whose only test is "did I get a blob" scores six successes out of six on that run while writing four wrong files ^[17]. Even the size heuristic is no help at real dimensions: the fallback is 17 percent of the WebP at the probe's 2x2 size ^[16], a gap that says nothing about a 4000-pixel export.

The AVIF row is the one that reorders priorities. Chrome decodes AVIF perfectly well in an `img` element and will not produce one from canvas ^[11], because encode and decode are separate code paths shipped on separate schedules ^[12]. Safari 16 has the same asymmetry, and nothing mainstream encodes HEIC at all ^[12]. An export menu offering HEIC is offering PNG with a different suffix.

Which is why the version table is the wrong instrument. Every browser on iOS is WebKit underneath, so "is this Safari" answers nothing useful, and in-app webviews report system versions that do not line up with the standalone browser. A user who enables Request Desktop Website will hand a phone's capabilities over a macOS user agent ^[6]. The string answers who the client claims to be; the question is whether it can encode WebP at this moment, and engine version, OS version, host app and build flags all sit in between ^[7]. Canvas has no `isTypeSupported` and no `encodingInfo`, though MediaRecorder and Media Capabilities both do ^[8], so the information has to be produced rather than looked up: a 2x2 canvas, one semi-transparent pixel so alpha is probed at the same time, one `toBlob` per MIME type, and the comparison `blob.type === mime`, cached ^[13].

The deeper defect in the original code is naming. If `blob.type` is the only field that tells the truth ^[3], then it, not the requested MIME, should decide the extension. Code that writes `output.webp` because it asked for WebP is asserting a fact it never verified, and the person who discovers the error is downstream with a hex editor ^[1].