¿Por qué mi PNG solo se reduce 10% — esperaba más?

La ganancia de recodificación sin pérdida depende enteramente de cuán bien estuviera ya optimizado el PNG origen. Los editores de imagen modernos (Adobe Photoshop, Affinity, Sketch) a menudo producen PNGs decentemente optimizados por defecto, dejando poco margen para más ganancias DEFLATE. Los PNGs exportados de la web (clic derecho → Guardar como) tienden a venir de servidores ya optimizados. Las mayores ganancias (20–30%) típicamente vienen de capturas PNG de herramientas de SO antiguas, PNGs exportados de herramientas mal configuradas, o archivos explícitamente guardados con baja compresión por velocidad. Si necesitas reducción sustancial de tamaño en un PNG, la respuesta correcta suele ser 'este contenido no debería ser PNG' — convierte a JPG (para fotos) o WebP (para fotos y gráficos) en su lugar.

Comprimir PNG online — Recodificación DEFLATE Sin Pérdida vía UZIP

Q: ¿Cómo puede un PNG hacerse más pequeño si ya es sin pérdida?

PNG (W3C 2ª Edición, 10 noviembre 2003 / ISO/IEC 15948:2004) es sin pérdida pero el tamaño de archivo depende de elecciones del codificador que la spec no fija: qué de los 5 tipos de filtro (None, Sub, Up, Average, Paeth) se aplica por línea de exploración, y qué nivel de compresión zlib (1–9) se usa para el paso DEFLATE (RFC 1951 Deutsch, mayo 1996). Un codificador PNG ingenuo elige defaults que producen un archivo funcional pero no el más pequeño posible. La vía UZIP de browser-image-compression (usada por esta herramienta) recodifica con selección de filtro optimizada y nivel zlib más alto, ahorrando típicamente 5–30% con cero cambios de píxel. Cada valor de píxel permanece bit-exacto idéntico a la entrada.

Q: ¿Esta herramienta es compresión PNG sin pérdida o con pérdida?

Estrictamente sin pérdida. El pipeline es decodificar-PNG-a-píxeles → recodificar-vía-UZIP-DEFLATE sin paso de cuantización. Cada valor de píxel se preserva bit-exacto. Para compresión PNG con pérdida con cuantización de paleta (RGBA 32 bits → PNG indexado 8 bits, ahorros hasta 70%) necesitarías una herramienta usando libimagequant/pngquant (Kornel Lesinski, proyecto ImageOptim, GPL-3.0) — pero pngquant cambia los valores de color mapeándolos a una paleta reducida, que es visualmente indistinguible para muchas imágenes pero técnicamente con pérdida. Esta herramienta compress-png NO hace cuantización de paleta; si necesitas ese nivel de reducción de tamaño, usa pngquant de escritorio o convierte a WebP/AVIF en su lugar.

Q: ¿Afecta el slider de calidad a la salida PNG?

No, el slider de calidad no tiene efecto en PNG. PNG es sin pérdida por spec — no hay perilla de calidad que ajustar. La variación de tamaño viene de la selección de filtro (5 tipos por línea de exploración) y nivel de compresión DEFLATE (1–9). La vía UZIP de browser-image-compression elige valores optimizados automáticamente; no los controlas. Si la UI de tu herramienta muestra un slider de calidad para entrada PNG, eso típicamente solo es significativo cuando el usuario convierte el PNG a un formato diferente (JPG, WebP) — para recompresión pura PNG-a-PNG, el slider es solo informativo.

Q: ¿Sobrevive la transparencia PNG a la compresión?

Sí, exactamente. PNG (W3C 2ª Edición) admite tanto alfa por entrada para PNG indexado (chunk tRNS) como alfa pleno de 8 bits (modo RGBA). La recodificación DEFLATE basada en UZIP de la herramienta preserva cada byte alfa bit-exacto — sin composición, sin aplanado, sin reducción de profundidad alfa. Esto es a diferencia de la conversión PNG → JPG (donde el alfa debe aplanarse contra un fondo) o PNG → WebP (donde el alfa se preserva pero el formato cambia). La recompresión PNG-a-PNG es la operación más segura posible para contenido con mucha transparencia (logos, iconos, capturas con alfa).

Compresor PNG — Recodificación DEFLATE Sin Pérdida (RFC 1951)

PNG (W3C Recommendation 10 noviembre 2003 / ISO/IEC 15948:2004) es sin pérdida por diseño — la compresión DEFLATE (RFC 1951 Deutsch, mayo 1996, LZ77 + Huffman con ventana deslizante de 32 KB) preserva cada píxel exactamente. La ganancia de compresión viene enteramente de elecciones del codificador no fijadas por la spec: qué de los 5 tipos de filtro (None, Sub, Up, Average, Paeth) se aplica por línea de exploración, y qué nivel de compresión zlib (1–9) se usa para el paso DEFLATE. La vía UZIP de browser-image-compression (Vanc, photopea, licencia MIT) recodifica sin pérdida con selección de filtro optimizada y nivel zlib más alto que los codificadores PNG ingenuos, ahorrando típicamente 5–30% con CERO cambios de píxel — cada valor de píxel permanece bit-exacto idéntico a la entrada. Crítico: esta herramienta NO hace cuantización de paleta (que sería con pérdida). Para PNG con pérdida con reducción de tamaño hasta 70% vía conversión RGBA 32 bits → indexado 8 bits, necesitarías libimagequant/pngquant (Kornel Lesinski, proyecto ImageOptim, GPL-3.0).

Relacionado: Comprimir JPG Comprimir WebP Comprimir Imagen Comprimir PNG Redimensionar Imagen Divisor de Cuadrícula

Cómo comprimir un PNG

Arrastra un archivo .png a la herramienta o haz clic para seleccionar — archivo suelto o lote.
La herramienta enruta a través de UZIP DEFLATE (saltando Canvas que produce PNG no optimizado).
El slider de calidad NO tiene efecto — PNG es sin pérdida. El tamaño de salida depende de la selección de filtro + nivel zlib (auto-seleccionados).
Revisa los tamaños antes/después (típico: reducción 5–30% según el nivel de optimización del PNG origen), luego descarga.

Casos de uso comunes

Optimizar capturas PNG antes de subir a un CMS de documentación — reducción típica de tamaño 10–25%.
Aligerar logos e iconos PNG para uso web sin conversión con pérdida — preserva bordes nítidos y colores exactos.
Reducir assets UI transparentes (sprites de cursor, exportaciones Figma) para bundles de app donde cada byte cuenta.
Re-optimizar PNGs de exportaciones de CMS antiguos o salidas de herramienta de diseño con poca optimización que dejaron compresión sobre la mesa.

Preguntas frecuentes

¿Cómo puede un PNG hacerse más pequeño si ya es sin pérdida?

PNG (W3C 2ª Ed) es sin pérdida pero el tamaño de archivo depende de elecciones del codificador no fijadas por spec: qué de los 5 tipos de filtro por línea de exploración + nivel de compresión zlib. La recodificación basada en UZIP (vía PNG de browser-image-compression) optimiza ambos, ahorrando 5–30% con cero cambios de píxel.

¿Esta herramienta es compresión PNG sin pérdida o con pérdida?

Estrictamente sin pérdida. Pipeline es decodificar-PNG-a-píxeles → recodificar-vía-UZIP-DEFLATE. Cada píxel preservado bit-exacto. Para cuantización de paleta PNG con pérdida (hasta 70% ahorro) necesitarías libimagequant/pngquant (GPL-3.0) — esta herramienta NO hace eso.

¿Por qué mi PNG solo se reduce 10%?

La ganancia de recodificación sin pérdida depende de cuán bien optimizada estaba ya la fuente. Los editores modernos (Photoshop, Affinity) producen PNGs decentemente optimizados por defecto. Si necesitas reducción sustancial, convierte a JPG (para fotos) o WebP (para gráficos con alfa) en su lugar.

¿Afecta el slider de calidad a la salida PNG?

No. PNG es sin pérdida por spec. El tamaño depende de la selección de filtro (5 tipos por línea de exploración) + nivel de compresión DEFLATE (1–9). UZIP elige valores optimizados automáticamente.

¿Sobrevive la transparencia PNG a la compresión?

Sí, exactamente. PNG (W3C 2ª Ed) admite tRNS de 1 bit + RGBA pleno de 8 bits. UZIP DEFLATE preserva cada byte alfa bit-exacto — sin composición, sin aplanado. PNG-a-PNG es la operación más segura posible para contenido con mucha transparencia.

Por qué PNG comprime menos que JPG — y cuándo 'lo bastante pequeño' no lo es

El mandato sin pérdida de PNG es a la vez su fortaleza y su techo de tamaño. El algoritmo DEFLATE (RFC 1951) logra ganancias típicas de recodificación sin pérdida del 5–30% sobre fuentes PNG mal optimizadas, pero no puede acercarse a las reducciones de 40–70% de JPEG porque no puede descartar ninguna información. Los 5 tipos de filtro por línea de exploración (None, Sub, Up, Average, Paeth) funcionan prediciendo cada byte desde bytes vecinos y codificando solo la diferencia — filtros bien elegidos exponen patrones que DEFLATE comprime ajustadamente, pero ninguna selección de filtro puede comprimir una imagen inherentemente compleja arbitrariamente. Los editores de imagen modernos (Adobe Photoshop, Affinity, Sketch) típicamente producen PNGs decentemente optimizados por defecto, dejando poco margen para más ganancias DEFLATE. Las mayores ganancias (20–30%) vienen de capturas PNG de herramientas de SO antiguas, PNGs exportados de CMSes mal configurados, o archivos explícitamente guardados con baja compresión por velocidad. Si tu PNG es contenido fotográfico guardado como PNG (una elección común pero subóptima en flujos de diseño), la respuesta correcta suele ser 'este contenido no debería ser PNG' — convierte a JPG (para fotos) o WebP (para fotos y gráficos, con soporte alfa) para reducción sustancial de tamaño. La librería browser-image-compression de amplio uso (Donaldcwl, licencia MIT) omite Canvas para PNG — el codificador PNG de Canvas produce salida no optimizada — y usa UZIP, una implementación JavaScript pura de DEFLATE, para compresión que se acerca a lo que herramientas del lado servidor como zopflipng u oxipng logran. La transparencia PNG (paleta tRNS de 1 bit o RGBA pleno de 8 bits) se preserva bit-exacta a través del round-trip; sin composición, sin reducción de profundidad alfa.

Recodificación DEFLATE sin pérdida vía UZIP (RFC 1951 Deutsch, mayo 1996)
Selección de filtro optimizada (None, Sub, Up, Average, Paeth — 5 tipos por línea de exploración según W3C 2ª Ed)
Nivel de compresión zlib más alto que codificadores PNG ingenuos basados en Canvas
Canal alfa preservado bit-exacto (chunk tRNS + modo RGBA de 8 bits)
Comparación de tamaño en tiempo real con porcentaje de ahorro
Librería browser-image-compression + UZIP.js (photopea, MIT) — sin cuantización de paleta, estrictamente sin pérdida

Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).

Fuentes (5)

W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — PNG is lossless by design (5 filter types per scanline + DEFLATE compression); compression here is lossless re-encoding with potentially better filter selection.
Deutsch, P. (1996). DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF (May 1996, Aladdin Enterprises) — LZ77 + Huffman with 32 KB sliding window; PNG IDAT compression algorithm; browser-image-compression's UZIP path re-applies DEFLATE with potentially higher zlib compression level.
Kutskir, I. (Photopea) (live). UZIP.js — JavaScript DEFLATE/INFLATE. github.com/photopea/UZIP.js (MIT license) — pure-JavaScript DEFLATE implementation by Photopea founder; used by browser-image-compression for PNG re-compression in browsers without native server-side optimisers.
WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/png') is universally supported but produces unoptimised output; browser-image-compression bypasses Canvas for PNG and uses UZIP for better compression).
Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT) — UZIP-based PNG re-encoding pipeline used by this tool (lossless DEFLATE re-encoding, NOT palette quantisation).

Son las especificaciones del W3C, ISO/IEC, ITU-T e IETF que la herramienta implementa o sobre las que se apoya. Localízalas en w3.org, iso.org, itu.int o datatracker.ietf.org.

Patrocinado

Por Marco B. · Última verificación mayo 2026 — corre en tu navegador