Summary

  • RFC 9649 defines how WebP container bytes are reconstructed, but the media type, magic sequence and a successful decode do not authenticate metadata, provenance or visual meaning.
  • Readers should ignore unknown chunks while writers should preserve them unless intentionally modifying them; interpretation, custody and endorsement are therefore separate decisions.
  • A defensible media record joins the original bytes and chunk inventory to decoder version, resource policy, metadata selection, decoded pixels, animation timing, derivative bytes and the final observed render.

A correct picture can be an incomplete record

RFC 9649 gives WebP a stable public specification and registers image/webp. It describes a RIFF container that can carry lossy VP8 data, a lossless bitstream, transparency, colour profiles, animation, EXIF, XMP and application-specific chunks. That is an important interoperability boundary. It tells independent readers how to turn bytes into a canvas.

It does not make the canvas the whole object. Two files can decode to the same visible pixels while carrying different metadata or unknown chunks. Two readers can accept the same bytes while selecting different short-frame timing or background treatment. A valid file can still force dangerous memory, CPU or parser behaviour. A media-type label can name the grammar without authenticating who created the file or whether any embedded assertion deserves reliance.

The institutional mistake is to let successful rendering inherit every missing conclusion. “The image opened” becomes “the object is safe.” “The pixels match” becomes “the provenance survived.” “The metadata is present” becomes “the claim is true.” RFC 9649 supports none of those promotions.

Reconstruction and custody follow different rules

The extended format makes one distinction especially useful. Chunks required for reconstruction and colour correction must appear in the defined order. Depending on the file, that sequence can include VP8X, ICCP, ANIM, ANMF, ALPH, VP8 and VP8L. A reader should fail when the chunks needed to reconstruct the image are out of order.

Metadata and unknown chunks have more freedom. EXIF, XMP and application-specific chunks may appear outside the reconstruction order. Unknown chunks may occur at the end of the file or at the end of an animation-frame payload. Readers should ignore them. Writers should preserve them in their original order unless they deliberately intend to modify them.

That asymmetry is not a loophole; it is an extensibility design. A reader released today can display tomorrow's file without pretending to understand a future chunk. An editor can rewrite visible image data without silently destroying application information it does not know. But the rule also exposes a governance boundary. Ignoring a chunk is not a finding that it is harmless or irrelevant. Preserving one is not a finding that it is accurate, authorised or safe for another application to interpret.

Every transformation service therefore makes at least three decisions. It decides which bytes it understands, which uninterpreted bytes it will carry forward, and which bytes it will remove or rewrite. A final file hash records the result of those decisions. It cannot explain them.

Metadata can be present without becoming truth

WebP can carry EXIF and XMP. RFC 9649 says there should be at most one chunk of each type. If duplicates appear, a reader may ignore every instance except the first. That modest rule matters in an evidence chain. A tool that keeps the first block, a tool that rewrites one canonical block and a tool that strips all metadata can each produce a decodable image. Their visible output may be identical while their assertions differ.

CIPA's Exif specification defines a metadata structure. Adobe's XMP specifications define another extensible metadata model and ways to embed it. Neither container mechanism authenticates every value. Camera name, creation time, author, location, edit history and rights fields remain claims whose source, signing context and custody must be evaluated separately.

This is where Lu Heng's Reality Layers becomes practical. Stored bytes, parsed fields, asserted provenance, decoded pixels and reader belief sit next to one another, but they are not one reality. A metadata tag can exist without being accurate. Accurate metadata can be stripped while pixels remain unchanged. A byte-identical original can be rendered under a different colour or compositing policy.

Invisible colour is still data

The lossless format restores ARGB pixel values exactly, including the colour values of pixels whose alpha value is zero. A fully transparent pixel contributes nothing visible when composited normally, but its red, green and blue components have not ceased to exist.

This is not evidence of a hidden message in any particular file. It is a reason not to equate invisible with absent. A later operation may drop alpha, place the image on an unexpected background, use the colour channels during processing or transcode them differently. A privacy scrubber that looks only at the rendered picture can miss information that a byte or decoded-pixel inspection would find.

The same distinction works in the other direction. If an optimiser normalises colour under transparent pixels, the displayed result may remain identical while the decoded pixel matrix changes. “Lossless” describes the specified codec round trip. It does not promise that every later editing service preserves the entire original container, every metadata claim or every application-specific byte.

One animation can have several observed timings

An animated WebP frame carries position, dimensions, duration, blending and disposal instructions. The stored frame duration uses milliseconds, but RFC 9649 leaves a duration of zero—and often a duration of ten milliseconds or less—to implementation interpretation. Many browsers and tools apply a minimum.

The background colour also illustrates bounded authority. It may contain non-opaque alpha even when the alpha feature flag is unset, and viewers should treat it as a hint rather than a mandatory display value. Blending and disposal determine how one frame changes the canvas before the next arrives.

The byte sequence is therefore not a complete observation of the performance. To make a claim about what a user saw, record the reader, version, timing normalisation, colour management, compositing background, playback conditions and captured output. A format-level instruction and a human-visible event are joined by software policy.

Validity is not a decoder safety verdict

RFC 9649's security section is unusually direct. Demuxing and decoding can expose integer overflow, out-of-bounds reads and writes, uninitialised data, null dereferences, memory or disk exhaustion and extended computation. Inputs can reach browsers, mail clients and servers that accept uploads. Consequences can include code execution, information leakage, crashes and denial of service.

The format has no active-content mechanism. That does not make its processing passive. Canvas dimensions drive allocation. Animation multiplies frames and work. Prefix codes, transforms and compressed image data drive parser state. EXIF, XMP and custom chunks may reach additional interpreters with their own attack surfaces.

A receiver needs a safety receipt that is independent of syntax acceptance: decoder library and version, process isolation, memory and time limits, maximum dimensions and frame count, metadata parsers invoked, error result and any derivative produced. A file that conforms to the grammar can still be rejected by local resource policy. A malformed file can sometimes be partially displayed by a tolerant implementation. Neither behaviour should be silently promoted into a universal format judgment.

Build a byte–chunk–render receipt

Begin with custody. Hash the exact received object, record its byte count, transport content type, filename claim and any independent type sniffing. Parse RIFF boundaries without yet declaring the object safe. Record every chunk's FourCC, offset, declared size, padding and order.

Then classify each chunk: required for reconstruction, recognised metadata, recognised application data, or unknown. Record whether the current operation understood, ignored, preserved, stripped, reordered or rewrote it. For duplicate EXIF or XMP, state which value was selected. For VP8X, retain canvas dimensions and feature bits; for animation, retain frame rectangles, durations, blend and disposal modes.

Run the decoder inside a bounded environment and record its identity, version and resource policy. Hash decoded pixels or individual frames where that is the relevant comparison. Record ICC handling, alpha policy, compositing background and duration normalisation. If an optimiser or editor creates a derivative, give that object its own hash and repeat the chunk inventory rather than calling it “the same image.”

Finally, observe the delivery surface. Record which object the browser or application fetched, which decoder handled it, whether every frame played, and which visual result was captured. Running-Code Primacy supplies the discipline: the registered grammar matters, but the executed reader and observed output decide what actually happened.

Keep the specification small and the local decisions visible

RFC 9649 does not need to become a provenance constitution. Its strength is the bounded byte and reconstruction contract. Minimum Initial Specification explains why that restraint matters: standardise what must interoperate, then keep future and local choices explicit.

One organisation may strip all metadata on public delivery. Another may preserve unknown chunks for archival custody. A third may reject animation, impose smaller canvas limits or require a signed external manifest. Those are legitimate local policies if they are named, versioned and observable. They become dangerous when hidden behind a generic “optimised” or “sanitised” label.

The correct governing sentence is narrow. RFC 9649 can prove that bytes satisfy a shared WebP grammar. It cannot prove who authored their claims, which uninterpreted data still matters, whether the decoder ran safely, whether a transformation preserved custody, or what a person finally saw. Those conclusions require receipts from the systems that actually made them.

Sources