PNG ファイルは PNG シグネチャとそれに続くチャンクの連続から成り立ちます。この章はシグネチャのチャンクの基本的な属性を定義します。それぞれのチャンク形式は次章で述べます。
PNG ファイルの最初の 8-byte は以下の（十進の）値を常に格納します：
137 80 78 71 13 10 26 10
このシグネチャはファイルの残りが IHDR チャンクから始まり、IEND チャンクで終わる連続したチャンクで構成されるひとつの PNG イメージを格納していることを示しています。
論拠は PNG file signatureを参照してください。
それぞれのチャンクは 4 つの部分から成り立ています：
231
チャンクのデータ長は最大値までのどんなバイト数でもとれます。したがって、アプリケーションはチャンクがどのような境界でそろえられているとも仮定することはできません。
それぞれのチャンクが置かれる位置に制限がありますが、チャンクはどのような順番でも現れることができます。（ひとつの著しい制限が IHDR は最初に現れねばならず、IEND は最後に現れねばならないというものです。したがって、IEND チャンクはファイル終端の指標をつとめます）。同じ形式で複数のチャンクが現れることができますが、はっきりと許可された形式のときのみです。
論拠は：Chunk layout を参照してください。
チャンク形式コードはデコーダがその形式コードを認識できなくともチャンクのいくつかの属性を決定できるように割り振られています。これらの規則はデコーダが未知のチャンクに出会ったときにどのように振る舞うか決定することを認めることで、 PNG の安全で柔軟性のある拡張を考慮する意図があります。命名規則はデコーダがチャンクの形式を認識できるときは関心をはらわれることはありません。
コード形式のそれぞれのバイトの bit 5 （値 32）の 4-bit はチャンクの属性を伝えるために使われます。この選択は人間が形式コードのそれぞれの文字が大文字（ bit 5 が 0 ）か小文字（ bit 5 が 1 ）かにより割り振られた属性を読みとれるということを意味しています。しかしながら、デコーダは特定のビットを数学的にチェックすることで、未知のチャンクの属性をチェックするべきでしょう。文字が大文字か小文字かをチェックすることは遅く、地域特有の大文字小文字の定義が使われていたときには間違いさえします。
属性ビットがチャンク名の先天的な部分であり、それゆえどんなチャンク形式でも固定されるということに注意すべきでしょう。したがって、BLOB と bLOb は異なる属性の同じチャンクではなく、関係のないチャンク形式コードです。デコーダは単純に 4-byte を比較して形式コードを認識する必要があります。形式コードに大文字小文字の変換をかけることは正しくありません。
属性ビットの意味は：
ファイルの内容を意味があるように表示するために厳密には必要のないチャンクは「補助」チャンクとして知られています。デコーダが補助ビットが 1 の未知のチャンクで出会ったならそのチャンクしも安全で、イメージを表示する事ができます。時間チャンク（tIME）が補助チャンクの例です。
ファイルの内容を表示するために必要なチャンクは「必須」チャンクと呼びます。デコーダが補助ビットが 0 の未知のチャンクに出会ったなら、利用者にイメージの内容の情報は安全に解釈することができないということを利用者に示す必要があります。イメージヘッダーチャンク（IHDR）が必須チャンクの例です。
公開チャンクは PNG 仕様書の一部や、PNG の特殊目的の公開チャンク形式のリストに登録されているものです。アプリケーションはプライベートチャンク（不登録）を自分自身の目的のために定義することもできます。プライベートチャンクの名前は２番目の文字を小文字として持つ必要があり、公開チャンクは常に２番目の文字が大文字として割り当てられています。デコーダは機能上意味がないのでプライベートビットをチャックする必要がないことに注意してください。公開チャンクとプライベートチャンクの名前が衝突しないことを保証する単純に管理上の都合です。Additional chunk types、エンコーダへの勧告は：Use of private chunks を参照してください。
チャンク名の３番目の文字の大文字小文字の意味は将来の拡張のために予約されています。現時点ではすべてのチャンク名は３番目の文字が大文字です。（ PNG 仕様書の将来のバージョンではこのビットの意味が定義されているかもしれないので、デコーダは３番目の文字が小文字だということについて文句を言うべきではありません。３番目の文字が小文字のチャンクもほかの未知のチャンク形式と同様に扱うことで十分です。）
この属性ビットは純粋なデコーダには関係ありませんが、PNG エディタ（PNG ファイルを修正するようなプログラム）に必要とされます。このビットはファイルを修正したときの認識できないチャンクの適切な扱いについて定義します。
チャンクの複写安全ビットが 1 のとき、そのチャンク形式をソフトウェアが認識できてもできなくても、そしてファイルの修正の及ぶ範囲に関わらずそのチャンクは修正された PNG ファイルにコピーすることができます。
チャンクの複写安全ビットが 0 のとき、そのチャンクはイメージデータに依存しているということを示しています。プログラムが必須チャンクに対して追加、修正、削除、必須チャンクの並べ替えを含むどのような変更でもしたのなら、そのときは認識できない危険なチャンクは出力する PNG ファイルにコピーしてはいけません。（もちろん、プログラムがそのチャンクを認識するのであれば、適切に修正された版を出力するかどうか選択できます）。
補助 チャンクを追加、削除、修正、並べ替えしただけならばつねに PNG エディタはすべての認識できないチャンクをコピーすることができます。これは補助チャンクがほかの補助チャンクに依存することは許されないと言うことを暗示しています。
PNG エディタが必須チャンクを認識できないならとにかくエラーを報告しその PNG ファイルの処理を中止する必要があります。安全/危険の機構は補助チャンクに使われることを意図しています。複写安全ビットは必須チャンクでは常に 0 です。
PNG エディタに対する規則はさらに Chunk Ordering Rules で述べられています。
たとえば、仮想のチャンク形式名 bLOb は次の属性ビットを持ちます：
bLOb <-- 32-bit のチャンク形式コードをテキスト形式で表現 |||| |||+- 複写安全ビットは 1 (小文字 bit 5 は 1) ||+-- 予約ビットは 0 (大文字 bit 5 は 0) |+--- プライベートビットは 0 (大文字 bit 5 は 0) +---- 補助ビットは 1 (小文字 bit 5 は 1)
したがって、この名前は補助で公開で複写して安全なチャンクを意味しています。
論拠は：Chunk naming conventions を参照してください。
チャンクの CRC は ISO 3309 [ISO-3309] や ITU-T V.42 [ITU-T-V42] に定義されるような pre and post conditioning による標準的な CRC 手法を使って計算されます。利用される CRC の多項式は、
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
32-bit の CRC レジスタはすべて 1 で初期化され、データのそれぞれのバイトは最小のビット (1) から最大のビット (128) まで処理されます。すべてのデータのバイトが処理された後で、CRC レジスタは反転させられます（補数がかけられます）。この値は MSB が最初に送られ（ファイルに保存され）ます。バイトに分割し並べ替える目的で、32-bit CRC の最小のビットは x31 の係数として定義されます。
CRC の現実的な計算は計算の加速のために常にあらかじめ計算されたテーブルを使います。Sample CRC Code を参照してください。