PNG Compression Principle: Why Is DEFLATE Lossless?

Bottom line: PNG is lossless because it uses the DEFLATE algorithm — both LZ77 dictionary compression and Huffman coding are fully reversible mathematical operations, and the decompressed data is byte-for-byte identical to the original. PNG's compression pipeline is: pixel data first undergoes filter row prediction to eliminate redundancy between adjacent pixels, then is compressed with DEFLATE. A 3000x2000 UI screenshot goes from 17.2MB raw to 0.35MB as PNG — a 97.9% reduction — with every pixel value unchanged. Below, we explain from two perspectives: PNG file structure and DEFLATE algorithm principles.

If you're not yet familiar with overall image compression methods, we recommend reading Image Compression Guide: JPG/PNG/WebP Format Comparison first.

1. PNG File Structure: How Data Is Organized

A PNG file consists of a series of data chunks, each containing a type, length, data, and checksum. Understanding the purpose of these chunks is key to understanding PNG's internal structure.

Data Chunk	Full Name	Function	Required	Typical Size
Signature	PNG Signature	8-byte file identifier (89 50 4E 47 0D 0A 1A 0A)	Required	8 bytes
IHDR	Image Header	Basic image info (width/height/color depth/color type)	Required	25 bytes
IDAT	Image Data	Compressed pixel data (DEFLATE encoded)	Required	Variable (main body)
IEND	Image End	File end marker	Required	12 bytes
PLTE	Palette	Color palette (indexed color mode)	Required for indexed color	≤768 bytes
tRNS	Transparency	Transparency information	Optional	Variable
tEXt	Text	Text metadata (author/description etc.)	Optional	Variable
gAMA	Image Gamma	Gamma correction information	Optional	16 bytes

The most critical chunk in a PNG file is IDAT, which stores the pixel data after filter row prediction and DEFLATE compression. A 3000x2000 24-bit RGB image has approximately 17.2MB of raw pixel data (3000x2000x3 bytes), but after PNG compression, the IDAT section may be only 0.3-0.5MB. Compression effectiveness depends primarily on the repeatability of image content — large solid color areas achieve the highest compression ratios, while noisy photos achieve the lowest.

2. DEFLATE Algorithm Principle: LZ77 + Huffman Two-Step Compression

PNG's core compression engine is the DEFLATE algorithm, which consists of two steps: first, LZ77 dictionary compression eliminates repeated sequences; second, Huffman coding eliminates encoding redundancy. Both steps are lossless reversible operations — this is the fundamental reason PNG compression is lossless.

Step	Algorithm	Principle	Redundancy Eliminated	Reversibility
Step 1	LZ77	Find repeated byte sequences, replace with (distance, length) references	Repeated sequence redundancy	Fully reversible
Step 2	Huffman coding	Short codes for high-frequency data, long codes for low-frequency data	Encoding redundancy	Fully reversible

1. LZ77 Dictionary Compression

LZ77 is a "sliding window" dictionary compression algorithm. It maintains a sliding window (typically 32KB) and searches for the longest matching byte sequence within the window at the current position. If a match is found, the byte sequence is replaced with a (distance, length) reference; if no match is found, the raw bytes are output.

Example: Suppose the image data contains consecutive white pixels (RGB 255,255,255) repeated 1000 times. LZ77 finds this repeating pattern in the window; after recording the first triplet, the subsequent 999 triplets are all replaced by a single reference "go back 3 bytes, copy 3 bytes, repeat 999 times." 3000 bytes of raw data are compressed into a dozen bytes of reference sequences — over 99% compression.

Data Characteristic	LZ77 Compression Effect	Typical Compression Ratio	Reason
Large solid color areas	Excellent	95%+	Long repeated sequences, high reference substitution efficiency
Horizontal gradient	Good	70%-85%	Gradient patterns can be matched
Regular textures	Good	60%-80%	Texture repetition can be referenced
Random noise	Poor	0%-10%	No repeated sequences to match
Natural photos	Poor	5%-20%	Large pixel differences, few matches

2. Huffman Coding

The data output by LZ77 (a mix of references and raw bytes) is then processed through Huffman coding. The core idea of Huffman coding is: high-frequency symbols get short codes, low-frequency symbols get long codes, thereby reducing the average code length.

Example: If "reference markers" appear 60% of the time in LZ77 output, raw byte value 255 appears 20%, and other values each appear in small proportions. Huffman would assign "reference markers" a 2-bit code, 255 a 3-bit code, and low-frequency values 8-12 bit codes. This reduces the average code length per symbol from a fixed 8 bits to 3-4 bits, providing an additional ~50% compression.

DEFLATE uses two Huffman coding methods: fixed Huffman tree (preset encoding table, fast but average compression) and dynamic Huffman tree (builds optimal encoding table based on actual data frequencies, higher compression but requires storing the table). The PNG standard requires dynamic Huffman coding for optimal compression.

3. Lossless Compression Mechanism: Filter Row Prediction + DEFLATE

PNG's lossless compression relies not only on the DEFLATE algorithm but also on a crucial preprocessing step — filter row prediction (Filter). This step executes before DEFLATE, aiming to make pixel data more suitable for LZ77 compression.

Adjacent pixels in an image typically have similar values (e.g., pixels in a blue sky region have similar values). Filter row prediction converts each pixel value to the difference from its left or upper neighbor — differences are usually small or zero, and this data pattern is more suitable for LZ77 and Huffman compression.

Filter Type	Name	Prediction Formula	Suitable Scenario
0	None	No prediction, raw values	Irregular noisy data
1	Sub	Current value - left value	Horizontal gradient images
2	Up	Current value - upper value	Vertical gradient images
3	Average	Current value - (left+upper)/2	Smooth transition images
4	Paeth	Current value - Paeth predicted value	General (optimal for most images)

PNG encoders can independently choose filter types for each row. SmartSlim, based on its self-developed Rust compression engine, tries all 5 filter methods for each row and selects the one with the best compression — this reduces size by an additional 10%–20% compared to using a single fixed filter.

Complete compression pipeline:
Raw pixels -> Filter row prediction (select optimal filter) -> LZ77 dictionary compression -> Huffman coding -> IDAT data chunk

Decompression pipeline is fully reversed:
IDAT data chunk -> Huffman decoding -> LZ77 decompression -> Inverse filter restoration -> Raw pixels

Both steps are exact mathematical inverse operations — the decompressed pixel data is byte-for-byte identical to the original, which is the fundamental guarantee of PNG losslessness.

4. Benchmark: PNG vs JPEG vs WebP Size Comparison

We used the same set of test images to compare the compression effectiveness of three formats, covering different types of image content.

Image Type	Dimensions	Original BMP	PNG	JPEG(q80)	WebP(q80)	PNG Compression Ratio
UI screenshot	1920x1080	5.93MB	0.35MB	0.82MB	0.28MB	94.1%
Wireframe diagram	2000x1500	8.58MB	0.42MB	1.15MB	0.35MB	95.1%
Natural photos	3000x2000	17.16MB	12.50MB	1.80MB	1.42MB	27.2%
Portrait photo	4000x3000	34.33MB	28.80MB	3.50MB	2.80MB	16.1%
Icon set	1024x1024	3.00MB	0.08MB	0.45MB	0.06MB	97.3%
Scanned document	2480x3508	24.80MB	1.20MB	0.85MB	0.72MB	95.2%

The benchmark data reveals a key conclusion: PNG's compression effectiveness is highly dependent on image type. For UI screenshots, wireframe diagrams, icons, and other images with large solid color areas, PNG achieves 94%–97% compression — far exceeding JPEG. But for natural photos, portraits, and other images with large pixel differences, PNG achieves only 16%–27% compression — far less than JPEG's 89%–90%.

Looking at before/after PNG optimization, comparing standard PNG and optimized PNG:

Image Type	Standard PNG	Optimized PNG	Reduction After Optimization	Optimization Method
UI screenshot	0.42MB	0.35MB	16.7%	Paeth filter + zlib maximum level
Wireframe diagram	0.52MB	0.42MB	19.2%	Per-row optimal filter + remove metadata
Icon set	0.12MB	0.08MB	33.3%	Convert to 8-bit indexed color + optimized filter
Scanned document	1.50MB	1.20MB	20.0%	Per-row optimal filter + remove gAMA

SmartSlim's PNG optimization can reduce size by an additional 15%–33% compared to standard PNG, primarily through the combination of per-row optimal filter selection and maximum zlib compression level.

For more format comparisons, see Lossless vs Lossy Compression: Core Differences and WebP vs PNG vs JPG Format Comparison.

5. FAQ

Q1: Why is PNG lossless compression?

PNG uses the DEFLATE algorithm to compress data, which consists of two steps: LZ77 dictionary compression and Huffman coding. LZ77 finds repeated byte sequences and replaces them with distance+length references; Huffman uses variable-length codes so high-frequency data gets short codes. Both steps are reversible — during decompression, Huffman decoding restores variable-length codes, and LZ77 recovers original bytes from references. The data is completely identical with no information loss, which is why PNG is lossless compression.

Q2: Which has a higher compression ratio: PNG or JPEG?

For photos, JPEG's compression ratio is far higher than PNG's. A 3000x2000 photo is about 12.5MB as PNG and 1.8MB as JPEG quality 80 — a 7x difference. This is because JPEG uses lossy DCT transforms to discard high-frequency details, while PNG must losslessly preserve every pixel. However, for wireframe diagrams, screenshots, icons, and other images with large solid color areas, PNG is actually smaller — a UI screenshot is 0.3MB as PNG vs 0.8MB as JPEG quality 80. Format choice depends on content type.

Q3: What is the maximum PNG compression ratio?

It depends on image content. Images with large solid colors or gradients can achieve over 90% compression (e.g., a UI screenshot from 5MB to 0.3MB); noisy photos typically achieve only 10%-30% because pixel differences are large and LZ77 can't find repeated sequences. PNG's theoretical limit using the DEFLATE algorithm is approximately at ZIP compression levels — it cannot achieve the extremely high compression ratios that JPEG gets by discarding information.

Q4: What is the difference between PNG optimization and PNG compression?

PNG compression refers to encoding raw pixel data into PNG format using DEFLATE — the standard process. PNG optimization further reduces size on top of standard compression, including: trying all 5 filter row prediction methods to select the optimal one, using the maximum zlib compression level, removing metadata chunks (e.g., tEXt/gAMA), and converting 24-bit RGBA to 8-bit indexed color (if colors ≤256). SmartSlim's PNG optimization can reduce size by an additional 15%-30% compared to standard PNG.

Summary

PNG achieves lossless compression because both steps of the DEFLATE algorithm — LZ77 and Huffman — are fully reversible mathematical operations, combined with filter row prediction preprocessing that enhances data compressibility. PNG excels at compressing UI screenshots, wireframe diagrams, icons, and other images with large solid color areas (94%–97% compression ratio), but has limited compression for photos (16%–27%) — in such cases, JPEG or WebP should be chosen instead.

If you need to optimize PNG image size, SmartSlim provides per-row optimal filtering and maximum zlib compression based on its Rust compression engine, reducing size by an additional 15%–33% compared to standard PNG. It supports 9 image formats including png/jpg/jpeg/webp/bmp/tiff, with local compression that keeps data on-premises.