Summary

  • RFC 2083 made each letter of a four-byte PNG chunk type carry one property bit: critical or ancillary, public or private, reserved or current, unsafe or safe to copy.
  • The fourth bit was an editor rule, not a truth label. An unknown safe-to-copy ancillary chunk could survive changes, while an unknown unsafe chunk had to be dropped after critical image data changed.
  • A retained chunk and matching CRC proved bounded byte custody. They did not prove private-name uniqueness, semantic freshness, authorship, permission, privacy or the accuracy of the image's claim.

Imagine an editor opening a PNG, recoloring the image and writing new IDAT data. Between the familiar chunks sits a type the editor has never seen. The image can still be decoded without it, so the chunk appears ancillary. Its data might describe a histogram, a proprietary workflow state, a physical calibration or something else entirely. The editor cannot infer the meaning. Yet it still has to decide whether the unknown bytes belong in the output.

That was the narrow engineering problem RFC 2083 solved. The specification did not ask an old program to understand every future extension. It gave the program a small decision surface that remained readable even when the extension itself was unknown. Four bit positions, expressed through ASCII letter case, divided what a decoder could ignore, what namespace a name came from and what an editor could carry across a change.

Four letters were four separate instructions

A PNG chunk contains a length, a four-byte type code, data and a four-byte CRC. The type bytes are restricted to the ASCII letter ranges, but implementations are told to treat them as fixed binary values. Locale-sensitive case conversion is wrong. The relevant fact is bit 5, value 32, in each byte.

The first letter marks criticality. Uppercase means critical: an unknown type may contain information required to interpret the image, so the decoder must not pretend it understands the file. Lowercase means ancillary: the decoder may ignore the unknown chunk and continue to display the image. This is a fallback rule for ignorance, not a ranking of importance. Copyright text, calibration data or a timestamp can matter greatly to a human while remaining ancillary to extracting viewable pixels.

The second letter separates public and private chunk names. Uppercase marks a public name; lowercase marks a private one. RFC 2083 treated the bit as an administrative convenience rather than a decoder behavior switch. It kept future public assignments out of the private namespace, but it did not allocate unique private names. Two organizations could still use the same private type for incompatible meanings. The specification therefore recommended extra identifying information inside private chunk data.

The third letter was reserved. Conforming Version 1.0 names used uppercase there, while decoders were told not to fail merely because a future file used the lowercase form. The rule preserved space for a later extension without forcing an old implementation to invent its semantics.

The fourth letter was different because it addressed editing. Lowercase meant safe to copy; uppercase meant unsafe to copy. A pure decoder did not need that answer. A program writing a changed datastream did.

RFC 2083 illustrated the whole code with the hypothetical name bLOb: ancillary, public, reserved bit clear and safe to copy. The letters were not decoration. TEXT and Text would be different binary type codes, not one name styled two ways.

Safe to copy meant safe under a defined edit, not true forever

An unknown safe-to-copy ancillary chunk could be copied whether the editor changed a little or a lot. An unknown unsafe-to-copy ancillary chunk carried a dependency warning. If critical chunks had been added, deleted, modified or reordered, the editor had to omit that unknown chunk from the output. If only ancillary chunks changed, it could still preserve it.

The distinction assigned custody without demanding universal knowledge. The extension author declared whether unknown software could safely retain the bytes after the image's critical representation changed. The editor observed its own modification class and made a deterministic branch. Neither had to ask a central authority at edit time.

The bargain imposed limits on extension design. Ancillary chunks could depend on critical chunks, but they were not supposed to depend on other ancillary chunks. A dependency on the entire datastream could not be expressed by one safe-to-copy bit. RFC 2083 discouraged such designs; making them critical was possible, but portability would fall because unknowing decoders and editors would have to stop.

The current W3C PNG Third Edition preserves the same separation and sharpens ordering rules. An editor copying an unknown unsafe ancillary chunk must not move it relative to critical chunks. Even an unknown safe-to-copy chunk may not be moved from before IDAT to after IDAT or the reverse. Safe to copy therefore never meant safe to relocate without constraint.

A CRC closed one byte question and left the semantic question open

Every PNG chunk carries a CRC over its type and data fields. The CRC can expose accidental damage to those covered bytes. Separate CRCs let critical information such as dimensions be checked early. RFC 2083 also suggested that one private chunk could store the CRC of a chunk it depended on, such as PLTE, to detect whether that dependency had changed.

That is useful evidence, but it is not an interpretation engine. A matching CRC does not say who wrote the chunk, whether the type name collided with another private use, whether its claim was authorized or whether its meaning still fits newly edited pixels. Recomputing a CRC after rewriting bytes proves even less about the legitimacy of the rewrite: it shows that the new record is internally consistent under the checksum rule.

This matters for metadata that survives visual change. A crop, recolor or replacement of image data can leave an ancillary description syntactically intact while making it substantively stale. Conversely, dropping every unknown chunk may destroy information that was designed to remain valid. The fourth bit does not solve truth. It prevents an ignorant editor from having to guess the extension author's declared dependency on critical image data.

The Third Edition's privacy discussion makes the wider boundary visible. Some tools have historically hidden pixels with alpha or changed dimensions without removing recoverable image data; eXIf can also carry location information. Those are reasons to inspect the complete datastream and the effect of the edit. They do not turn safe-to-copy into a privacy classification.

The format grew feature by feature instead of changing one global number

RFC 2083 deliberately put no version number in the PNG signature or elsewhere in the file. Its rationale was practical. A global version could make an old decoder reject a file merely because the number was high, even when the file used no feature the decoder needed to understand. It also said little about private extensions.

Chunk properties made compatibility granular. A newer file remained usable by an older decoder when it introduced only unknown ancillary features. An unknown critical feature forced refusal. A private extension could choose either behavior according to whether the extension was essential to obtaining a reasonable image. Compatibility was therefore decided by the features actually present, not by one document-wide badge.

The modern extension record still shows that pattern. The W3C's PNG extensions document lists additional public chunks separately from the core specification and notes an unregistered type that can be encountered in real files. Registration, recognition and semantic support are separate facts. Publication makes a definition available; it does not install a decoder or prove that an editor preserved the right meaning.

Lu Heng's later account of a minimum initial specification and localized future decisions offers a useful retrospective lens. PNG fixed a thin common grammar—chunk framing, property bits and local validation rules—then let software accept, ignore or reject extensions according to the features it actually ran. This is a comparison across time, not a claim that the 1997 authors followed a theory written in 2026.

The more basic lesson is evidentiary. The reality-layers distinction separates an executable rule from a narrative attached to it. In a PNG editor, the property bit, the class of edit and the resulting copy/drop action are executable. “Official,” “safe,” “accurate” and “authorized” are larger claims. They need evidence that the chunk-name grammar does not contain.

The receipt should name the decision that was actually made

An audit of a PNG transformation should retain the input datastream hash, ordered chunk inventory, type bytes, property-bit interpretation, CRC results, the editor's known-type set, the exact critical and ancillary changes, every unknown chunk's copy/drop decision, output ordering and output hash. If metadata informs a public claim, preserve its schema, namespace owner, provenance and a reason it remains applicable after the image change.

That record avoids two opposite errors. One is blind preservation: keeping an unknown unsafe chunk after the pixels or palette changed and treating its CRC as proof that the metadata remains valid. The other is blind stripping: removing a safe, deliberately portable extension without recording the loss. Both erase the decision surface RFC 2083 took care to expose.

The fourth letter did not certify the metadata. It placed responsibility. The extension author declared a dependency class; the editor disclosed what it changed; the decoder admitted what it did not know. A robust evidence chain keeps those acts separate from the image a reader finally sees.

Sources