JPG se convierte a WebP para ~25-35% menos peso a calidad equivalente.WebP (Google, 2010) es un formato moderno que supera a JPG en compresión añadiendo soporte de canal alfa y animación. 97% de soporte en navegadores (Safari 14+ requerido); usa JPG si necesitas compatibilidad con clientes antiguos.
Comparativa JPG vs WebP
| Propiedad | JPG | WebP |
|---|---|---|
| Compresión | Con pérdida (DCT) | Con pérdida o sin (VP8 / VP8L) |
| Peso típico foto | 50-80 KB | 30-60 KB (~25-35% menor) |
| Canal alfa | No | Sí (RGBA) |
| Animación | No | Sí (desde 2010) |
| Profundidad de color | 8 bits/canal | 8 bits/canal |
| Año de introducción | 1992 (ISO 10918) | 2010 (Google, RFC 6386) |
| Soporte navegador | Universal (~100%) | 97% (Safari 14+, Chrome 32+, FF 65+) |
| Ideal para | Compatibilidad universal | Web moderna, menor ancho de banda |
| Metadatos EXIF | Soporte nativo | Soportado (desde libwebp 0.5) |
| Dimensiones máximas | 65.535 × 65.535 px | 16.383 × 16.383 px |
| Patentes | Todas expiradas (2007) | Libre de royalties (cesión Google) |
| Modo sin pérdida | No | Sí (VP8L, ~26% menor que PNG) |
Conversor JPG a WebP — Archivos 25–35% Más Pequeños vía Compresión Moderna
WebP (RFC 9649 Zern, Massimino y Alakuijala, Google LLC, noviembre 2024) es un formato de imagen moderno construido sobre keyframes de vídeo VP8 (RFC 6386 Bankoski et al., noviembre 2011) para el modo con pérdida y un pipeline LZ77 + codificación Huffman/prefix personalizado para el modo sin pérdida. Típicamente entrega archivos 25–35% más pequeños que JPEG (ITU-T T.81 / ISO/IEC 10918-1:1994, 18 septiembre 1992) a calidad perceptual equivalente, el resultado de predicción y codificación de entropía más eficientes versus el DCT codificado-con-Huffman más antiguo de JPEG. La conversión corre localmente vía la API Canvas 2D Context + HTMLCanvasElement.toBlob('image/webp', quality) de WHATWG. El soporte de navegador es asimétrico: Chrome 18+ (2012), Edge 79+ (basado en Chromium, enero 2020), Firefox 96+ (enero 2022) (98+ para parámetro de calidad, 105+ para sin pérdida vía quality=1.0), pero Safari NO soporta salida image/webp nativamente — los usuarios Safari recurren a polyfill o formato alternativo. Recodificar desde JPG no puede recuperar detalle que JPEG ya descartó; el WebP codifica los píxeles existentes de forma más compacta.
Cómo convertir JPG a WebP
- Arrastra un archivo .jpg a la herramienta o haz clic para seleccionar — archivo suelto o lote.
- Elige un nivel de calidad WebP (1–100). 80–85 es el punto dulce seguro — típicamente 25–35% más pequeño que el JPG origen sin pérdida perceptible de calidad.
- Observa la comparación de tamaño — la ventaja WebP es mayor en fotografías suaves (35%+) y menor en imágenes de color plano (15–25%).
- 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 una librería JPG legacy a WebP para mejorar Core Web Vitals (Largest Contentful Paint mejora con payloads de imagen más pequeños).
- Reducir fotos de producto en un e-commerce WebP-first, con fallback HTML <picture> JPG para Safari 13 / navegadores antiguos.
- Producir variantes WebP en una cadena de fallback <picture> para posts con muchas imágenes y landing pages.
- Recodificar un lote de JPGs exportados de cámara a WebP para ahorro de almacenamiento en cloud (reducción típica 25–30% a calidad 80).
Preguntas frecuentes
¿Cuánto más pequeño será el WebP vs el JPG origen?
WebP (RFC 9649, nov 2024) típicamente 25–35% más pequeño que JPEG a calidad perceptual equivalente. Fotos con gradientes suaves ven 35%+; contenido con bordes nítidos ve 15–25%. El ahorro viene de la predicción VP8 (RFC 6386, nov 2011) + codificador aritmético booleano para modo con pérdida / Huffman para sin pérdida vs DCT con Huffman estático de JPEG (T.81, sep 1992). Recodificar no puede recuperar detalle ya descartado por JPEG.
¿Safari soporta generar WebP desde JPG?
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).
¿Se transferirán los metadatos EXIF de JPG a WebP?
WebP admite chunk EXIF según RFC 9649 §2.7.1.5 que lleva los mismos metadatos EXIF 2.32 (JEITA CP-3451X, mayo 2019) que JPEG APP1. Pero las conversiones basadas en Canvas eliminan EXIF como efecto secundario del decodificar-a-píxeles-y-re-codificar. Beneficio de privacidad al compartir. Usa la herramienta de escritorio cwebp -metadata para preservar EXIF explícitamente.
¿Debería usar WebP con pérdida o sin pérdida para convertir JPG?
Con pérdida. Las fuentes JPG ya son con pérdida (la cuantización T.81 Anexo K es irreversible), así que WebP sin pérdida preservaría cada artefacto de bloque JPEG a 2–3× el tamaño WebP con pérdida sin ganancia de fidelidad. WebP con pérdida a calidad 80 = 25–30% más pequeño que el JPG origen, sin diferencia visible. WebP sin pérdida tiene sentido solo desde fuentes PNG/BMP/RAW.
¿Todos los navegadores de mis usuarios mostrarán la salida WebP?
Los modernos sí: Chrome desde 32 (2014), Edge ≥18 (2018), Firefox 65+ (ene 2019), Safari 14+ (16 sep 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 JPG para máxima compatibilidad.
Cómo WebP logra 25–35% más pequeño — y la limitación de salida en Safari
La ventaja de compresión de WebP viene de los modos de intra-predicción de VP8 (4 modos para macrobloques luma 16×16 + 4 para chroma 8×8 + 10 modos para sub-bloques luma 4×4 según RFC 6386 §11–12) que predicen valores de píxel desde bloques vecinos antes de codificar el residual, más codificación de entropía más eficiente (codificador aritmético booleano de VP8 para modo con pérdida; codificación Huffman/prefix para modo sin pérdida) que empaqueta entropía mejor que las tablas Huffman estáticas de JPEG. Para WebP con pérdida el pipeline refleja la codificación de keyframe VP8; para sin pérdida (RFC 9649 §3) usa LZ77 con caché de color y cuatro transformaciones reversibles (predictor, color, subtract-green, color indexado) antes de la codificación Huffman final. El resultado: una fotografía JPEG de 1 MB a calidad 85 típicamente codifica como WebP de 650–750 KB a calidad 80 sin pérdida perceptible. La vía de conversión aquí usa Canvas toBlob('image/webp') que, críticamente, NO está soportada en Safari a fecha de 2026 — una limitación de WebKit rastreada en bugs.webkit.org. Chrome soportó codificación WebP nativa desde la versión 18 (2012); Edge ≥79 (basado en Chromium, enero 2020) hereda el mismo codificador; Firefox la añadió en la versión 96 (enero 2022) con el parámetro de calidad llegando en Firefox 98 y sin pérdida vía quality=1.0 en Firefox 105. Los usuarios Safari convirtiendo JPG a WebP necesitan o un polyfill (p.ej., libwebp compilado a WebAssembly) o una herramienta de escritorio. Para sitios que soportan usuarios Safari, AVIF se muestra en Safari 16+ (sept 2022) pero Safari tampoco soporta canvas.toBlob('image/avif') de salida — la misma limitación de WebKit que image/webp output.
- JPEG origen decodificado según ITU-T T.81 / ISO/IEC 10918-1 baseline DCT
- Salida WebP según RFC 9649 (keyframes VP8 lossy según RFC 6386 + modos lossless)
- Calidad WebP ajustable 1–100 (Firefox 98+ / Chromium desde 2010)
- Reducción típica de tamaño 25–35% a calidad perceptual equivalente
- Codificación nativa de navegador en Chrome / Edge / Firefox 96+; Safari requiere polyfill
- En navegador vía WHATWG Canvas toBlob('image/webp', quality) — sin subida, sin servidor
Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).
Fuentes (5)
- ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — source JPEG baseline DCT bitstream.
- Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — defines target WebP container; image/webp media type registration; lossy + lossless + animated modes.
- 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.
- JEITA / CIPA (2019). Exchangeable image file format for digital still cameras: Exif Version 2.32. JEITA CP-3451X / CIPA DC-X008-2019 (revised 17 May 2019 — JPEG APP1 EXIF; WebP container can carry EXIF in EXIF chunk per RFC 9649).
- WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (browser conversion mechanism: decode JPG → toBlob('image/webp', quality); native WebP encoding in Chrome / Edge / 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
Por Marco B. ·