= Deflate block framing
{c}
Each block starts with a one-<bit> `BFINAL` flag and a two-<bit> `BTYPE` field. The `BTYPE` values are 0 for stored data, 1 for fixed <Huffman codes>, 2 for dynamic <Huffman codes>, and 3 for an invalid reserved value. For compressed blocks, symbol 256 ends the current block; `BFINAL = 1` says this is the last block. An end-of-block symbol does not mean a literal zero <byte>, and in a nonfinal block it does not end the whole stream.<DEFLATE Compressed Data Format Specification version 1.3 by L. Peter Deutsch>[RFC 1951, section 3.2.3: header, block types and decoding loop]{ref}
\Image[/deflate-token-block-pipeline.png]
{title=Deflate separates literal and copy instructions from Huffman coding and final-block framing; stored blocks bypass both stages}
A stored block instead skips to the next <byte> boundary, reads the sixteen-<bit> `LEN` and its sixteen-<bit> one's complement `NLEN`, then copies exactly `LEN` raw <bytes>. Its length field replaces the compressed block's end-of-block symbol. A compressed block need not end at a <byte> boundary, so the next block header can start inside the current <byte>.<DEFLATE Compressed Data Format Specification version 1.3 by L. Peter Deutsch>[RFC 1951, sections 3.2.3 and 3.2.4: alignment, LEN, NLEN and stored data]{ref}
The diagram shows logical fields, not a serialization into <bits>. RFC 1951 specifies <bit> packing separately, including different conventions for <codewords> and other fields (section 3.1.1). For <PNG>, the filtered image data is compressed inside a zlib wrapper with its own header and checksum; raw <Deflate> and a complete <PNG> file therefore have different framing.<Portable Network Graphics (PNG) Specification (Third Edition) by Mark Adler and others>[PNG Specification, Third Edition, sections 10.1 and 10.2: zlib wrapper and filtered image data]{ref}
Back to article page
