¿Por qué mi WebP no se hace más pequeño — esperaba ahorros sustanciales?

Probablemente porque el WebP origen ya estaba bien codificado. Recodificar un WebP con pérdida ya optimizado al mismo nivel de calidad produce ahorros mínimos (a menudo <5%) ya que la cuantización de VP8 es en gran parte determinista — re-correr el codificador reproduce salida casi idéntica. La ganancia viene de recodificar a una calidad MENOR que la fuente. Si la fuente era calidad 90 y recodificas a calidad 80, espera reducción de 30–40% con pérdida visible menor. Nota: recodificar WebP con pérdida a través de cualquier ajuste de calidad siempre introduce pérdida generacional adicional como JPEG, así que siempre recodifica desde un máster sin pérdida si está disponible.

Comprimir WebP online — Recodificar vía VP8 (Con Pérdida) o LZ77+Huffman (Sin Pérdida)

Q: WebP con pérdida vs sin pérdida — ¿cuál elegir?

Depende del contenido origen. WebP con pérdida (keyframes VP8 según RFC 6386 Bankoski et al., noviembre 2011) a calidad 80–85 típicamente entrega archivos 25–35% más pequeños que JPEG equivalente a la misma calidad perceptual, sin artefactos visibles en fotografías. WebP sin pérdida (LZ77 + codificación Huffman/prefix + caché de color + cuatro transformaciones reversibles según RFC 9649 Zern, Massimino y Alakuijala, Google LLC, noviembre 2024 §3) preserva cada píxel exactamente — promediando ~26% más pequeño que PNG equivalente según el WebP Compression Study de Google. Para contenido fotográfico ve con pérdida; para gráficos/logos/iconos ve sin pérdida.

Q: ¿Sobrevivirá la transparencia WebP a la compresión?

Sí. WebP admite un canal alfa de 8 bits tanto en modo sin pérdida como en extensión del modo con pérdida (chunk ALPH según RFC 9649 §2.7.1.2). El pipeline de compresión (ya sea nativo del navegador vía Canvas toBlob('image/webp', quality) o polyfill libwebp WebAssembly en Safari) preserva los valores alfa exactamente — cada píxel transparente permanece transparente, cada píxel semi-transparente mantiene su byte alfa preciso. La recompresión WebP-a-WebP es alfa-limpia en todos los navegadores y niveles de calidad.

Compresor WebP — VP8 Con Pérdida o LZ77+Huffman Sin Pérdida (RFC 9649)

WebP (RFC 9649 Zern, Massimino y Alakuijala, Google LLC, noviembre 2024) admite dos modos de compresión distintos. El modo con pérdida usa keyframes VP8 (RFC 6386 Bankoski et al., noviembre 2011) — calidad 1–100 controla el cuantizador VP8, con 80–85 el punto dulce web típico entregando archivos 25–35% más pequeños que JPEG equivalente. El modo sin pérdida usa LZ77 + codificación Huffman/prefix + caché de color + cuatro transformaciones reversibles (según RFC 9649 §3) — preserva cada píxel exactamente mientras promedia ~26% más pequeño que PNG equivalente según el WebP Compression Study de Google. La herramienta enruta a través de Canvas toBlob('image/webp', quality) donde calidad 0–1 mapea al escalado del cuantizador VP8 para con pérdida; Firefox 105+ admite quality=1.0 para activar el modo sin pérdida. Salvedad crítica de Safari: Safari NO soporta salida image/webp vía canvas.toBlob() a fecha de 2026 — una limitación de WebKit rastreada en bugs.webkit.org. Los usuarios Safari se topan con un polyfill libwebp WebAssembly vía la librería browser-image-compression.

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

Cómo comprimir un WebP

Arrastra un archivo .webp a la herramienta o haz clic para seleccionar — archivo suelto o lote.
Elige un nivel de calidad. 80–85 es el punto dulce web típico para con pérdida; quality=100 (o 1.0 en Firefox 105+) activa el modo sin pérdida.
Observa el porcentaje de ahorro. Las ganancias de recodificación WebP-a-WebP dependen mucho de la calidad previa del WebP origen — los WebPs bien optimizados dejan poco margen.
Descarga la copia comprimida. Nota: si estás en Safari, la conversión usa polyfill libwebp WebAssembly (ligeramente más lento que nativo).

Casos de uso comunes

Recomprimir assets WebP legacy a menor calidad (85 → 75) para reducir el peso total de página antes de una auditoría Lighthouse.
Producir variantes WebP sin pérdida desde WebPs ya con pérdida generalmente NO se recomienda — convierte desde un máster sin pérdida si está disponible.
Aligerar capturas WebP para documentación o bundles de assets donde el original se guardó a alta calidad.
Preparar variantes WebP para etiquetas HTML <picture> con fallbacks PNG/JPG para audiencias Safari pre-14 / iOS pre-14.

Preguntas frecuentes

Compresión WebP con pérdida vs sin pérdida — ¿cuál elegir?

Depende de la fuente. Con pérdida (VP8 según RFC 6386, nov 2011) a calidad 80–85 típicamente 25–35% más pequeño que JPEG, sin artefactos visibles en fotos. Sin pérdida (RFC 9649 §3 LZ77 + Huffman + caché de color) preserva píxeles exactamente, ~26% más pequeño que PNG según Google. Fotos → con pérdida; gráficos → sin pérdida.

¿Soporta Safari la codificación WebP para esta herramienta?

No nativamente a fecha de 2026 — una limitación de WebKit rastreada en bugs.webkit.org. Chrome 18+ (2012), Edge 79+ (ene 2020), Firefox 96+ (ene 2022) soportan nativamente. Los usuarios Safari se topan con un polyfill libwebp WebAssembly (incluido por la librería browser-image-compression).

¿Cómo se compara la calidad WebP con la calidad JPEG?

Según el WebP Compression Study de Google, WebP con pérdida a calidad 80 es 25–35% más pequeño que JPEG calidad 80 con calidad perceptual comparable, gracias a la intra-predicción más granular de VP8 (10 modos para sub-bloques luma 4×4 más 4 modos cada uno para macrobloques luma 16×16 y chroma 8×8 según RFC 6386 §11–12) y la codificación de entropía aritmética vs el DCT 8×8 + Huffman más antiguo de JPEG.

¿Sobrevivirá la transparencia WebP a la compresión?

Sí. WebP admite alfa de 8 bits en ambos modos sin pérdida y con pérdida (chunk ALPH según RFC 9649 §2.7.1.2). La compresión preserva los bytes alfa exactamente a través de las vías nativa de navegador y polyfill WebAssembly.

¿Por qué mi WebP no se hace más pequeño?

Probablemente porque el WebP origen ya estaba bien codificado. Recodificar a la misma calidad produce ahorros mínimos (a menudo <5%) ya que la cuantización VP8 es en gran parte determinista. La ganancia viene de recodificar a una calidad MENOR — 90 → 80 típicamente reducción 30–40% con pérdida visible menor.

Con pérdida o sin pérdida — eligiendo por contenido + la salvedad de codificación Safari

Los dos modos de compresión de WebP encajan limpiamente con tipos de contenido distintos. WebP con pérdida (keyframes VP8 según RFC 6386) brilla en contenido fotográfico — 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) más codificación de entropía aritmética booleana empaquetan la entropía de imagen natural ~25–35% más eficientemente que el DCT 8×8 + Huffman de JPEG de 1992. WebP 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/prefix final — preservando cada píxel exactamente, ~26% más pequeño que PNG equivalente según el estudio publicado de Google. Semántica del slider de calidad: 1–100 controla el cuantizador VP8 para con pérdida; Firefox 105+ reconoce quality=1.0 como activador sin pérdida. La recompresión compone la pérdida como JPEG: recodificar un WebP ya con pérdida a menor calidad degrada más; siempre recomprime desde un máster sin pérdida si está disponible. Asimetría de soporte de navegador: Chrome 18+ (2012), Edge 79+ basado en Chromium (enero 2020), Firefox 96+ (enero 2022) todos soportan salida image/webp nativamente; Safari NO — una limitación de WebKit que requiere polyfill libwebp WebAssembly (incluido por browser-image-compression). El polyfill produce salida bit-idéntica a la codificación nativa; la única diferencia es el rendimiento (WebAssembly ligeramente más lento que la implementación VP8 nativa). Metadatos EXIF: WebP admite chunk EXIF según RFC 9649 §2.7.1.5, pero la recodificación basada en Canvas lo elimina por defecto — opt-in preserveExif lo retiene vía flag de browser-image-compression.

Calidad 1–100 controla el cuantizador VP8 para WebP con pérdida (RFC 6386)
WebP sin pérdida vía quality=1.0 (Firefox 105+) — preserva píxeles vía LZ77 + Huffman + caché de color
Codificación nativa de navegador en Chrome 18+ / Edge 79+ / Firefox 96+; Safari usa polyfill libwebp WebAssembly
Canal alfa preservado (chunk ALPH según RFC 9649 §2.7.1.2) en ambos modos con pérdida y sin pérdida
Metadatos EXIF eliminados por defecto (beneficio de privacidad) — opt-in preserveExif vía browser-image-compression
Comparación de tamaño en tiempo real con porcentaje de ahorro

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

Fuentes (5)

Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — WebP container with lossy mode (VP8 keyframes) and lossless mode (LZ77 + Huffman/prefix coding + colour cache); quality 1–100 controls VP8 quantiser for lossy.
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 underlying WebP lossy mode; intra-prediction modes packed by boolean arithmetic coder.
WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/webp', quality) native in Chrome 18+, Edge 79+ Chromium, Firefox 96+; Firefox 105+ supports lossless via quality=1.0; Safari does NOT support image/webp output — requires libwebp WebAssembly polyfill).
Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT) — Canvas-based WebP re-encoding pipeline used by this tool; falls back to libwebp WebAssembly polyfill in Safari.
Google LLC (WebP team) (live). WebP Compression Study. developers.google.com/speed/webp/docs/webp_study — SSIM-based comparison; lossless WebP averages ~26% smaller than equivalent PNG; lossy WebP at quality 80–85 typically 25–35% smaller than JPEG.

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