PNG se convierte a WebP para ficheros ~26% menores a calidad idéntica (modo sin pérdida).WebP conserva la transparencia con canal alfa y añade animación + modo con pérdida. Usa WebP sin pérdida como reemplazo directo de PNG en navegadores modernos (97% soporte); mantén PNG solo para compatibilidad con sistemas antiguos.
Comparativa PNG vs WebP
| Propiedad | PNG | WebP |
|---|---|---|
| Compresión | Sin pérdida (DEFLATE) | Sin pérdida (VP8L) o con (VP8) |
| Peso sin pérdida | 200-500 KB | ~150-370 KB (~26% menor) |
| Modo con pérdida | No | Sí (calidad 1-100) |
| Canal alfa | Sí (RGBA) | Sí (RGBA) |
| Animación | No (usa APNG) | Sí (nativa, desde 2010) |
| Profundidad de color | 8 o 16 bits/canal | 8 bits/canal |
| Año de introducción | 1996 (RFC 2083) | 2010 (Google, RFC 6386) |
| Soporte navegador | Universal (~100%) | 97% (Safari 14+, FF 65+) |
| Ideal para | Compatibilidad universal | Web moderna, menor ancho de banda |
| Metadatos EXIF | Vía chunks tEXt / iTXt | Soportado (libwebp 0.5+) |
| Dimensiones máximas | 2³¹−1 px por lado | 16.383 × 16.383 px |
| Patentes | Sin patentes desde 1996 | Libre de royalties (Google) |
Conversor PNG a WebP — 26% Más Pequeño Sin Pérdida o 50–80% Con Pérdida
WebP (RFC 9649 Zern, Massimino y Alakuijala, Google LLC, noviembre 2024) supera a PNG en tamaño en ambos modos de codificación. Según el WebP Compression Study de Google, los archivos WebP sin pérdida son aproximadamente 26% más pequeños que los PNG equivalentes (W3C Recommendation 10 noviembre 2003 / ISO/IEC 15948:2004). WebP con pérdida a calidad 80–85 típicamente entrega reducción de 50–80% en PNGs fotográficos sin pérdida perceptible. El ahorro viene de los modos de predicción de VP8 (RFC 6386 Bankoski et al., noviembre 2011) para el modo con pérdida y del pipeline LZ77 + codificación Huffman/prefix + caché de color + cuatro transformaciones reversibles para el modo sin pérdida (RFC 9649 §3). PNG usa DEFLATE sin pérdida (RFC 1951 Deutsch, mayo 1996, LZ77 + Huffman) que es universal pero menos eficiente en compresión. Ambos formatos admiten alfa de 8 bits (PNG tRNS / RGBA; chunk ALPH de WebP según RFC 9649 §2.7.1.2) así que la transparencia hace round-trip sin pérdida. El soporte de navegador es asimétrico: Chrome 18+ (2012), Edge 79+ (basado en Chromium, enero 2020), Firefox 96+ (enero 2022) codifican WebP nativamente, pero Safari NO soporta salida image/webp vía toBlob() a fecha de 2026 — una limitación de WebKit que requiere un polyfill JavaScript (típicamente libwebp compilado a WebAssembly).
Cómo convertir PNG a WebP
- Arrastra un archivo .png a la herramienta o haz clic para seleccionar — archivo suelto o lote.
- Elige WebP sin pérdida (calidad 100) para gráficos/logos/iconos/capturas UI; elige WebP con pérdida a calidad 80–85 para contenido PNG fotográfico.
- Observa la comparación de tamaño — reducciones típicas: ~26% sin pérdida, 50–80% con pérdida en fotos. Ahorros menores en imágenes de color plano que PNG ya comprime eficientemente.
- Descarga el WebP. Nota: si estás en Safari, la conversión usa un polyfill JavaScript ya que Safari no soporta codificación WebP nativa.
Casos de uso comunes
- Migrar assets PNG pesados a WebP para reducir el peso de página en un sitio moderno (mejora Largest Contentful Paint, especialmente para hero images).
- Producir variantes WebP en un <picture> con fallbacks PNG para usuarios en navegadores antiguos (Safari 13 / iOS 13 y anteriores).
- Sustituir capturas PNG por WebP sin pérdida en documentación con muchas imágenes — preserva la nitidez del texto con ~26% reducción de tamaño.
- Aligerar logos y assets UI a WebP sin pérdida para bundles de app más pequeños, apps móviles y PWAs offline-first.
Preguntas frecuentes
¿Cuánto más pequeño será el WebP vs el PNG origen?
Según el WebP Compression Study de Google, WebP sin pérdida es ~26% más pequeño que PNG. WebP con pérdida a calidad 80–85 reduce las fuentes PNG fotográficas 50–80% sin pérdida perceptible. El ahorro viene de la predicción VP8 (RFC 6386, nov 2011) para con pérdida + LZ77 + codificación Huffman/prefix + caché de color para sin pérdida (RFC 9649 §3). PNG usa DEFLATE sin pérdida (RFC 1951).
¿Safari soporta generar WebP desde PNG?
No de forma nativa. Safari NO soporta salida image/webp en HTMLCanvasElement.toBlob() a fecha de 2026 — una limitación de WebKit. Chrome 18+ (2012), Edge 79+ Chromium (ene 2020), Firefox 96+ (ene 2022) sí lo hacen nativamente. Los usuarios de Safari recurren a un polyfill JavaScript (libwebp compilado a WebAssembly es la elección típica).
¿Debería usar WebP con pérdida o sin pérdida para convertir PNG?
Depende del contenido PNG. Los PNGs sin pérdida (logos, iconos, capturas, line art) deberían convertirse a WebP sin pérdida (quality=100 / Firefox 105+ quality=1.0) — preserva cada píxel exactamente, ~26% más pequeño según el estudio de Google. Los PNGs fotográficos deberían convertirse a WebP con pérdida a calidad 80–85 — 50–80% más pequeño sin pérdida visible.
¿Las áreas transparentes del PNG seguirán siendo transparentes en el WebP?
Sí. La transparencia tRNS de paleta + RGBA de 8 bits de PNG (W3C 2ª Ed) mapea directamente al canal alfa de WebP vía el chunk ALPH (RFC 9649 §2.7.1.2). La conversión Canvas preserva los bytes alfa exactamente. Esta es la dirección round-trip limpia para contenido PNG con mucha transparencia.
¿Todos los navegadores de mis usuarios mostrarán la salida WebP?
Los modernos sí. Visualización WebP: Chrome 32+ (2014), Edge 18+ (2018), Firefox 65+ (ene 2019), Safari 14+ (16 sept 2020 / iOS 14), Opera 19+ (2014). Los antiguos (IE 11, Safari 13 / iOS 13 y anteriores) no muestran WebP. Usa HTML <picture> con fuente WebP + fallback PNG para máxima compatibilidad.
Sin pérdida o con pérdida — eligiendo según tipo de contenido PNG
El contenido PNG cae en dos categorías naturales que mapean limpiamente a los modos de codificación WebP. Los gráficos de color plano, logos, iconos, capturas de UI y line art deberían típicamente convertirse a WebP sin pérdida (quality=100 o quality=1.0 en Firefox 105+) — cada píxel preservado exactamente, bytes alfa intactos vía el chunk ALPH (RFC 9649 §2.7.1.2), con ~26% de ahorro de tamaño de media según el WebP Compression Study de Google. El ahorro no será drástico para imágenes de color plano (el DEFLATE de PNG según RFC 1951 ya maneja color plano eficientemente con modo paleta), pero la conversión es sin pérdida en términos de fidelidad. El contenido PNG fotográfico (imágenes naturales guardadas como PNG para pipelines de edición, capturas de fotos, exportaciones de herramientas de diseño de material de cámara) debería convertirse a WebP con pérdida a calidad 80–85 — la codificación predictiva de VP8 más el codificador aritmético de entropía empaquetan la entropía de imagen natural mucho más eficientemente que DEFLATE, entregando reducción de 50–80% sin pérdida perceptible para la mayoría de espectadores. El caso de PNG-como-fotografía es inusual pero común en flujos de trabajo de diseño gráfico donde el PNG era un máster sin pérdida temporal antes de la exportación web final. La vía de conversión usa WHATWG Canvas 2D Context + HTMLCanvasElement.toBlob('image/webp', quality) que corre nativamente en Chrome / Edge / Firefox 96+; los usuarios de Safari recurren a un polyfill libwebp WebAssembly ya que Safari no soporta salida image/webp vía toBlob (una limitación de WebKit rastreada en bugs.webkit.org). Los archivos WebP de salida se muestran correctamente en todo navegador moderno incluyendo Safari 14+ (16 septiembre 2020 / iOS 14) — solo la dirección de codificación está restringida en Safari.
- PNG origen decodificado según W3C 2ª Edición (alfa + DEFLATE según RFC 1951)
- Salida WebP según RFC 9649 (modo sin pérdida preserva PNG exactamente con ~26% ahorro; modo con pérdida 50–80% más pequeño para fotos)
- Calidad WebP ajustable 1–100 (Firefox 98+ / Chromium desde 2010)
- Modo sin pérdida vía quality=1.0 (Firefox 105+) o quality=100 en otros — round-trip PNG garantiza cero pérdida de píxeles
- Canal alfa preservado de extremo a extremo (PNG tRNS / RGBA → chunk ALPH WebP según RFC 9649 §2.7.1.2)
- Codificación nativa de navegador en Chrome 18+ / Edge 79+ / Firefox 96+; Safari requiere polyfill
Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).
Fuentes (6)
- W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — source format with alpha channel + DEFLATE lossless compression.
- Deutsch, P. (1996). DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF (May 1996, Aladdin Enterprises — LZ77 + Huffman; source PNG IDAT compression to be unwound during conversion).
- Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — target WebP container; lossless mode preserves PNG's pixel-exact data.
- Google LLC (WebP team) (live). WebP Compression Study. developers.google.com/speed/webp/docs/webp_study + webp_lossless_alpha_study — SSIM-based PNG vs WebP comparison; lossless WebP averages ~26% smaller than equivalent PNG over public test suites + web-crawled corpus.
- Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., & Xu, Y. (Google Inc.) (2011). VP8 Data Format and Decoding Guide. RFC 6386, IETF (November 2011, Informational) — VP8 keyframe bitstream used by WebP lossy mode (alternative target for size-prioritised conversions).
- WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (browser conversion mechanism: decode PNG → toBlob('image/webp', quality); native WebP encoding in Chrome 18+, Edge 79+, Firefox 96+ since January 2022; Safari does NOT support image/webp output natively as of 2026).
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.
Guías relacionadas
- Compresión de imágenes para Core Web Vitals — Lo que realmente impactaLos cambios de optimización de imágenes que de verdad mejoran LCP, CLS e INP — con cifras reales. Salta los mitos, envía los que mueven la métrica.
- PNG vs JPG vs WebP — Árbol de decisión prácticoDeja de adivinar qué formato usar. Un árbol de decisión real para PNG, JPG y WebP según tipo de contenido, transparencia y restricciones de entrega.
- WebP vs AVIF en 2026 — Cuál usar y cuándoWebP y AVIF merecen la pena en 2026, pero resuelven cosas distintas. Comparativa práctica: compresión, soporte, velocidad de codificación y fallbacks.
Por Marco B. ·