On July 9th, someone uploaded a reference image saved straight out of a browser's 'save image as' dialog. The declared content type was image/png. The actual bytes were AVIF. Our upload path trusted the declared type, forwarded the file downstream as if it were a PNG, and every request that touched it failed, because the vendor on the other end was never given the format it thought it had. The fix wasn't a special case for that one browser quirk. It was to stop trusting declared types at all.

Reading the bytes instead of the label

Every image reference uploaded to VisionX is now sniffed at the byte level before it goes anywhere near a generation engine. Modern image containers like AVIF and HEIC share the same underlying box structure, ISOBMFF, which means a naive sniff can genuinely mistake one for the other. We parse the actual ftyp box in the file header to tell them apart, because the vendor engines behind VisionX accept HEIC and reject AVIF, and getting that distinction wrong in either direction means a reference that silently fails or silently gets treated as something it is not.

This matters more than a single incident: it means a file's name, its extension, and whatever content type a browser or OS decided to declare are all treated as hints, never as ground truth. The bytes are ground truth. That single change is why an AVIF mislabeled as PNG can no longer take down a request the way it did in July.

An honest failure beats a doomed retry

Format sniffing also has to tell two different failure modes apart, because they need different responses. Some AVIF files use an AV1 encoding profile our decoding stack genuinely cannot open, a real, permanent limitation, not a fluke. Others fail for transient reasons that are worth a retry. Forwarding either kind of failure downstream without distinguishing them means either wasting a generation attempt on bytes that were never going to decode, or telling a user "try again" when trying again will never help. We check which situation it is before the file goes anywhere, and the error a user sees reflects which one actually happened.

The same discipline, upstream of upload

The same normalization runs whether an image arrives as a direct upload, a Google Drive or Dropbox link, or a raw URL paste, and reference images are content-hash deduplicated on the way in, so the same file uploaded twice does not create two separate vendor-side registrations or burn double the storage. None of that is visible in the product. It is exactly the kind of plumbing that is only visible when it is missing, which is the point of writing it down here instead of leaving it as a comment only an engineer will ever read.

The lesson wasn't really about AVIF. It was that a content-type header is a claim, not a fact, and the moment you build a system that treats a claim as a fact, someone's browser will eventually prove you wrong. Ours already did, once. It won't get the chance again.