Cuantización PNG frente a compresión con pérdida: Datos reales de 1000 imágenes

June 26, 2026 · 6 min read

I manage image pipelines for a living. When someone asks "should I use pngquant or TinyPNG?" my answer used to be "depends on the image." That's a cop-out. So two weekends ago I grabbed 1,000 random PNGs from the web—screenshots, logos, product photos, illustrations, icons, UI mockups, charts—and ran every one through both pipelines. Here's what the numbers actually say.

Quantization vs Lossy: What's Actually Different

These two approaches reduce PNG file size in fundamentally different ways, and I find most articles blur the distinction into "they both make files smaller."

Quantization (pngquant, pngnq) reduces the color palette. A standard PNG uses 24-bit color—16.7 million possible colors per pixel. Quantization maps those colors to a smaller palette, typically 256 colors (8-bit) or fewer. The compression is lossy in the color space—you lose subtle gradients—but the image structure stays intact: same dimensions, same alpha channel, same pixel grid.

Lossy compression (TinyPNG, imagemin-pngquant with quality flags) goes further. It applies quantization plus additional filtering that can blend nearly-identical adjacent pixels. This is lossy in the spatial sense—the image literally changes at the pixel level, not just the palette level.

The difference matters more in practice than in theory. Here's why.

The 1,000-Image Benchmark

I categorized each image by type and ran three pipelines:

Image TypeAvg BaselineQuantizationLossyLossy vs Quant
Screenshots (UI)247KB89KB (-64%)52KB (-79%)42% smaller
Photographs1.2MB380KB (-68%)210KB (-82%)45% smaller
Logos & Icons34KB12KB (-65%)11KB (-68%)8% smaller
Illustrations156KB43KB (-72%)31KB (-80%)28% smaller
Charts & Graphs89KB28KB (-69%)24KB (-73%)14% smaller
The pattern is clear: Lossy compression provides the biggest wins on photographs and screenshots—images with continuous tones and subtle gradients. On logos, icons, and charts—images with flat colors and sharp edges—quantization alone does 90%+ of the work. The extra lossy step saves almost nothing on these image types.

Where Lossy Goes Wrong: Three Image Types I Won't Compress Aggressively

I found three categories where aggressive lossy compression caused visible artifacts in more than 10% of images:

Heatmaps and data visualizations. Lossy posterization can blend adjacent color bins in a heatmap, making two distinct data values look identical. I spotted this in 6 out of 20 chart images—subtle enough to miss at a glance, significant enough to misrepresent data. For anything with a color legend, I stick to quantization only at quality 90+.

Text-heavy screenshots. Lossy compression introduces ringing artifacts around sharp edges—like the borders of letters. On a 12px font screenshot, this makes text look slightly fuzzy. Quantization alone preserves the hard edges because it only reduces colors, not spatial detail.

Images with alpha transparency. PNG's alpha channel stores pixel-by-pixel opacity. Aggressive lossy compression can produce banding in semi-transparent regions—shadows, glows, glass effects. I found 14 images in my batch where the lossy output had visible transparency banding that the quantization-only output didn't.

My Pipeline Decision Rules (After Looking at 1,000 Files)

After spending a weekend staring at compression artifacts, here's the flowchart I now follow:

I use compress2png.com for quick one-offs—it handles both quantization and lossy compression in the browser, and the side-by-side preview lets me catch artifacts before downloading. For CI/CD pipelines, pngquant + zopflipng in a Docker container with the quality thresholds above.

The biggest lesson from 1,000 images: "just make it smaller" isn't a strategy. The right compression method depends on what's in the image, and the wrong one either wastes bytes (quantization on photos) or creates artifacts (lossy on charts). Match the method to the content, and you'll hit the sweet spot every time.

Maria RodriguezWritten by Maria Rodriguez — DevOps Engineer. I optimize image delivery pipelines and benchmark compression tools for a living. More about me →