His Screenshots Were Eight Megabytes Each. Lossless Does Not Mean Incompressible.
A developer uploading screenshots to a product documentation site noticed his pages loading slowly on mobile connections. The images were PNG files exported directly from his screen recording software. They looked fine. They were also enormous, some running five to eight megabytes for a single screenshot.
PNG is lossless, which means the format preserves every pixel. That property is valuable for images that need to maintain precision. It is also the reason unoptimized PNG files are routinely much larger than necessary.
The misunderstanding is that lossless means incompressible. PNG compression is real and significant. A PNG file exported from a screenshot tool at default settings and a PNG file compressed with a tool optimized for web delivery can differ by 60 to 80 percent in file size with no visual difference whatsoever. Understanding why requires a short detour into why PNG was created in the first place.
Why PNG Exists: A Patent Dispute in 1994
PNG was born from a legal crisis. On December 28, 1994, Unisys Corporation announced it would enforce its patent on the Lempel-Ziv-Welch (LZW) compression algorithm used inside the GIF format. Any software that read or wrote GIF files would have to pay royalties. The internet, which had built its image infrastructure heavily on GIF, reacted with alarm.
Within days, Thomas Boutell posted a discussion thread on the Usenet newsgroup comp.graphics proposing a free alternative. The discussion moved fast. On January 4, 1995, Tom Lane and others proposed using the DEFLATE compression algorithm, which was not covered by any patent. Oliver Fromme suggested the name PNG on January 6, 1995. By early February 1995, seven specification drafts had been produced. The PNG specification was published as a W3C Recommendation in 1996 and later formalized as ISO standard 15948 in 2004.
The choice of DEFLATE shaped everything about how PNG compression works and why there is so much room to optimize it.
How PNG Compression Actually Works
PNG uses a two-stage process. The first stage is filtering, which transforms the raw pixel data before any compression occurs. The filter step predicts each pixel's value based on its neighbors and stores only the difference between the prediction and the actual value. For smooth gradients or large areas of uniform color, those differences are often close to zero. Lots of zeros compress dramatically better than varied pixel values.
Five filter types are available per row: None, Sub (difference from left neighbor), Up (difference from pixel above), Average (average of left and above neighbors), and Paeth (a prediction formula developed by Alan W. Paeth and described in his 1991 SIGGRAPH paper). An encoder can choose a different filter for each row independently, and the optimal choice depends on the image content.
The second stage takes the filtered output and runs it through DEFLATE, a combination of LZ77 (which finds repeated byte sequences) and Huffman coding (which encodes frequent values with fewer bits). The PNG specification requires DEFLATE to conform to the zlib format, which adds a small header and checksum.
The key insight is that most screenshot tools choose reasonable but not optimal settings. They pick one filter mode for the entire image and use moderate DEFLATE effort levels. An optimizer revisits those decisions: it tries all five filter modes per row, tests different DEFLATE strategies, and picks whichever combination produces the smallest output. The image data is identical. The encoding choices are better.
Where the Big Gains Come From
Color depth is often where the largest savings live. PNG supports several bit depths: 1-bit for black and white, 8-bit for indexed color (up to 256 colors with a stored palette), 16-bit per channel for high-precision images, and 24-bit for standard full color. Screenshot tools almost universally default to 24-bit color, even when the image contains far fewer than 256 distinct colors.
A screenshot of a terminal window, a code editor, or a simple web application often uses fewer than 200 distinct colors. Stored as an 8-bit indexed PNG rather than 24-bit, the file needs roughly one-third the color data per pixel. The savings compound with the filtering and DEFLATE stages, because indexed data with a limited palette compresses much better than raw 24-bit data.
Metadata also adds size without adding visual information. PNG files can carry text chunks, GPS data, color profile data (ICC profiles), creation timestamps, and application-specific chunks inserted by whatever software created the file. Adobe Photoshop, for instance, embeds extensive metadata by default. For images destined for a web browser, this data is typically invisible and unnecessary. Stripping it alone can reduce a file by several percent.
The Tools That Optimize PNG
The main lossless PNG optimizers have a clear hierarchy. PNGCrush, released in 1999, was one of the earliest dedicated PNG optimization tools and is still maintained for compatibility with existing pipelines. OptiPNG followed and is faster, making it practical for batch processing. OxiPNG, written in Rust and released more recently, is multithreaded and handles modern CPUs well, consistently producing smaller files than its predecessors. Zopfli, developed by Google engineers Jyrki Alakuijärvi and Lode Vandevenne and released in 2013, uses a more exhaustive search strategy and produces smaller files than OxiPNG in roughly 87 percent of cases, at the cost of significantly longer processing time.
For practical web use, the tradeoffs matter. OxiPNG at its default settings produces good results in a fraction of a second. Zopfli produces marginally smaller files but takes ten to thirty times longer per image. For a documentation site with hundreds of screenshots being rebuilt on every deploy, processing time is a real constraint. For a marketing image that will stay on a landing page for months, the extra compression from Zopfli may be worth the wait.
Browser support adds another option: WebP, developed by Google and announced in 2010, often produces smaller files than optimized PNG with no quality loss for most images. But WebP lacks universal support in older tools and some design workflows, and PNG remains the right choice when transparency is required alongside full color depth or when pixel-precise lossless encoding matters, such as for logos and interface screenshots.
What This Means for Web Performance
HTTP/2 and HTTP/3 have reduced the penalty for multiple requests, but image payload remains one of the primary contributors to slow page loads on mobile connections. HTTP Archive data consistently shows images accounting for 40 to 60 percent of average page weight on the web. PNG files that have not been compressed are one of the most tractable sources of that weight because the savings are lossless: there is no quality tradeoff to negotiate.
A documentation site with 50 screenshots at 5 MB each carries 250 MB of image data per full page load for users who have not cached anything. The same screenshots after optimization typically run under 1 MB each. On a 10 Mbps mobile connection, that difference is roughly 200 seconds of download time versus 5 seconds.
The optimization is not destructive and does not require keeping originals separately. The original pixel data is preserved exactly. The only change is how efficiently the encoding represents it.
Conclusion
PNG compression is one of the few web performance improvements with no downside. The format was designed from its origins in 1995 to support lossless compression, but the default settings in most software favor compatibility and speed over file size. An optimizer reconsiders those defaults and finds encodings the original tool did not bother to try.
For screenshots, diagrams, interface mockups, and any image where transparency or pixel precision matters, applying lossless compression before publication is standard practice at organizations that take performance seriously. ToolHQ's PNG compressor applies these optimizations automatically, testing filter settings and color depth to produce the smallest file that maintains exactly the original visual quality.
Frequently Asked Questions
Is PNG a lossless format?
Yes. PNG preserves all pixel data with no quality loss during compression. But lossless does not mean the file cannot be made smaller. Better compression settings can reduce PNG file size by 60 to 80 percent.
Why are screenshot PNG files so large?
Screenshot tools typically export at 24-bit color depth with default compression settings, which are not optimized for file size. The same screenshot with 8-bit color depth and optimized filters is dramatically smaller.
When should you use PNG instead of JPEG or WebP?
When transparency is required, when the image is a screenshot or UI element with flat colors, or when pixel accuracy must be preserved across multiple edits. Photos should use JPEG or WebP for better compression efficiency.