Convertir JPG a WebP gratis: guía completa 2026

Cambiar de JPG a WebP es de las intervenciones más baratas que existen sobre una web lenta: no hay que tocar el código, no hay que rediseñar nada y el resultado se nota en la primera carga. También es de las que más se explican mal. Circulan porcentajes de ahorro repetidos como si fueran una ley física, comparativas de conversores con límites que nadie ha comprobado y una idea equivocada de que el formato, por sí solo, arregla el rendimiento de una página. Esta guía va por otro lado: qué es WebP de verdad, qué gana y qué pierde cada imagen al convertirse, con qué herramienta hacerlo según el caso y en qué situaciones lo sensato es dejar el JPG donde está.

Qué es WebP y quién lo mantiene

WebP es un formato de imagen creado por Google y presentado en 2010. Su modo con pérdida reutiliza la técnica de codificación intra-fotograma del códec de vídeo VP8: en la práctica, una imagen WebP con pérdida es un fotograma clave de vídeo guardado como imagen fija. Un año después se le añadió un modo sin pérdida con un algoritmo propio, y más tarde llegaron el canal alfa y la animación. Todo eso vive dentro de un contenedor RIFF, el mismo tipo de estructura de bloques que usan los WAV, y por eso un archivo WebP empieza siempre por la firma RIFF seguida, cuatro bytes después, de WEBP.

El proyecto se mantiene como software libre bajo el nombre de libwebp, con licencia BSD. De ahí salen los binarios oficiales que casi todo el mundo acaba usando sin saberlo: cwebp para codificar, dwebp para decodificar, gif2webp, webpinfo y img2webp. Cuando ImageMagick, GIMP o un plugin de WordPress escriben un WebP, en la inmensa mayoría de los casos están llamando por debajo a esa misma biblioteca. Esto tiene una consecuencia práctica que conviene tener clara desde el principio: la herramienta que uses casi nunca cambia la calidad del resultado. Lo que cambia son los parámetros que te deja tocar y la comodidad del flujo de trabajo.

Que el formato sea abierto y sin regalías es lo que explica su adopción. No hay que pagar licencia por servir WebP, ni por incluir un codificador en un producto, ni por convertir un catálogo entero. Es la misma razón por la que después llegó AVIF con el mismo planteamiento desde la Alliance for Open Media.

Qué trae WebP que el JPEG no tiene

La comparación honesta no es solo de peso. Hay tres capacidades que el JPEG no puede ofrecer de ninguna manera:

• Canal alfa con pérdida. WebP admite transparencia de 8 bits incluso en su modo con pérdida. Antes de WebP, si querías transparencia tenías que irte a PNG y tragarte su peso; con WebP puedes tener un logo recortado sobre fondo transparente comprimido como una foto.
• Animación. El contenedor admite secuencias de fotogramas, así que WebP sustituye al GIF animado con muchísimo menos peso y con color de 24 bits en lugar de una paleta de 256.
• Modo sin pérdida real. El JPEG no tiene modo sin pérdida de uso general. WebP sí, y suele salir más compacto que un PNG con el mismo contenido.

Para el caso concreto de convertir un JPG, las dos primeras no aportan nada: un JPG no tiene transparencia ni animación, y convertirlo no se las va a inventar. Importan cuando el origen es un PNG o un GIF, no cuando es una fotografía.

Los límites del formato que casi nadie menciona

WebP tiene techos duros escritos en su especificación, y merece la pena conocerlos antes de meter un catálogo entero por el conversor:

• Dimensiones máximas de 16.383 × 16.383 píxeles. No es negociable: por encima de eso el archivo no se puede codificar. Para web sobra, pero para escaneos de gran formato, panorámicas o mapas es un muro real.
• 8 bits por canal y nada más. Ni 10 ni 12 bits, ni HDR. Si trabajas con fotografía en gama amplia o con material que va a pasar por una edición posterior, WebP es un formato de salida, no de trabajo.
• Submuestreo de croma fijo a 4:2:0 en el modo con pérdida. El JPEG te deja elegir 4:4:4 y conservar toda la información de color; WebP con pérdida siempre reduce la resolución de la crominancia a la mitad en ambos ejes. Se nota en bordes de color saturado sobre fondo contrastado: texto rojo sobre blanco, líneas finas de color, capturas de interfaz con acentos vivos. Ahí el modo sin pérdida es la respuesta.
• No hay renderizado progresivo. Un JPEG progresivo se muestra borroso y va afinándose mientras se descarga. Un WebP no aparece hasta que hay bytes suficientes. En conexiones lentas y en imágenes grandes, la percepción de velocidad puede favorecer al JPEG progresivo aunque el WebP pese menos.

WebP no es «JPEG pero mejor». Es un formato distinto, con otras fortalezas y otros techos. La decisión correcta depende del contenido de cada imagen, no de una preferencia general.

Con pérdida, sin pérdida y casi sin pérdida

Al convertir tendrás que elegir entre tres modos, y la elección importa más que la herramienta.

WebP con pérdida

Es el modo por defecto y el que usarás en el 90 % de los casos web. Se controla con un parámetro de calidad de 0 a 100. Conviene entender qué significa ese número: no es un porcentaje de calidad conservada ni es comparable entre formatos. Una calidad 80 en WebP y una calidad 80 en JPEG no producen el mismo resultado visual ni el mismo peso; son escalas internas de cada codificador. La utilidad oficial cwebp usa 75 por defecto, y para fotografías de web la zona razonable suele estar entre 70 y 85. Por debajo empiezan a verse bandas en cielos y degradados; por encima el archivo crece rápido sin que el ojo note la diferencia.

Hay un matiz importante cuando el origen es un JPG: estás recomprimiendo. El JPEG ya tiraba información y dejaba artefactos de bloque; el codificador WebP no sabe distinguir un artefacto de un detalle real, así que gasta bits en conservar el ruido de compresión del original. Es lo que se llama pérdida generacional. No suele ser visible con calidades altas, pero explica por qué un JPG ya muy comprimido no siempre adelgaza al pasar a WebP: parte de lo que hay que codificar es basura.

WebP sin pérdida

Conserva cada píxel del original decodificado. Para una fotografía casi nunca compensa: el archivo puede acabar pesando más que el JPG de partida, porque el JPG ya había tirado información y el WebP sin pérdida se obliga a guardar hasta el ruido. Para lo que sí sirve, y muy bien, es para capturas de pantalla, diagramas, gráficos con áreas planas, logos y cualquier imagen con bordes duros y pocos colores. En ese terreno compite con el PNG y suele ganarle.

WebP casi sin pérdida

Es un modo intermedio, activado con -near_lossless en cwebp. Aplica un preprocesado que simplifica ligeramente los píxeles para que el codificador sin pérdida encuentre más patrones repetidos, y luego codifica sin pérdida. El resultado es visualmente indistinguible del original en la mayoría de contenidos gráficos, con un archivo bastante más pequeño que el sin pérdida puro. Está infrautilizado y es la mejor opción para capturas de aplicaciones y documentación técnica.

Soporte en navegadores y dónde WebP todavía falla

El soporte en navegadores dejó de ser una objeción hace años. Chrome lo lleva desde sus primeras versiones, Firefox y Edge lo incorporaron después, Opera y Samsung Internet lo soportan, y Safari lo añadió en su versión 14, la que llegó con macOS Big Sur e iOS 14. Desde entonces, cualquier navegador que reciba actualizaciones de seguridad muestra WebP sin problemas. No hace falta manejar cifras de cuota de mercado para tomar la decisión: si tu público usa navegadores mantenidos, WebP se ve.

Lo que sigue sin estar resuelto es todo lo que ocurre fuera del navegador, y ahí es donde se cometen los errores:

• Correo electrónico. Varios clientes de escritorio no renderizan WebP y el destinatario ve un hueco vacío en la newsletter. Para email, JPG o PNG. Sin discusión.
• Imágenes de previsualización social. El og:image lo consumen rastreadores propios de cada plataforma, no navegadores. El soporte de WebP ahí es desigual y cambia sin aviso. Comprueba siempre el resultado con el depurador de la plataforma antes de dar la miniatura por buena; si dudas, deja un JPG.
• Software de terceros y flujos de impresión. Muchos programas de ofimática, de maquetación y de impresión aceptan WebP a regañadientes o directamente no lo abren. Si el archivo va a salir de tu web y acabar en manos de otra persona, envía el original.
• Documentos PDF y plantillas. Los generadores de PDF suelen esperar JPEG o PNG. Convertir la biblioteca entera a WebP y dejar de guardar el original rompe procesos que no tienen nada que ver con la web.

La regla que resume todo esto: WebP es un formato de entrega para navegadores. Es una versión derivada y optimizada de una imagen que debe seguir existiendo en otro sitio en su formato original.

Cuándo convertir compensa y cuándo no

Aquí está la parte que suele faltar en las guías. Convertirlo todo a WebP por defecto es una política tan mala como no convertir nada. Este es el criterio por tipo de imagen:

La pregunta del ahorro: por qué no hay una cifra

Es la duda que todo el mundo trae: cuánto voy a ahorrar. La respuesta honesta es que no existe un porcentaje aplicable a tu caso, y desconfía de quien te dé uno. El ahorro depende de tres variables que cambian con cada archivo:

1. Cómo estaba comprimido el JPG de partida. Un JPG recién salido de una cámara o de un móvil, con calidad casi máxima y metadatos completos, tiene muchísimo margen. Un JPG que ya pasó por un optimizador agresivo tiene muy poco.
2. El contenido de la imagen. Una foto con mucho grano, follaje o textura fina es difícil de comprimir para cualquier códec. Un retrato de estudio sobre fondo liso, o una captura de pantalla, se comprimen enormemente.
3. La calidad que elijas a la salida. Puedes conseguir el ahorro que quieras bajando la calidad. La pregunta útil no es cuánto ahorras, sino cuánto ahorras sin que se note.

El método correcto es medir con tus propias imágenes: coge diez representativas de tu sitio, conviértelas a dos o tres calidades, compara pesos y míralas al 100 % en la pantalla donde se van a ver. Con esa tabla en la mano tomas una decisión informada; con un porcentaje sacado de un artículo, no.

Convertir JPG a WebP en el navegador

La vía más rápida para una imagen suelta es un conversor que funcione dentro de la propia página, sin instalar nada. GlobalTool tiene uno en Convertir formato de imagen. El flujo es corto:

1. Abre la herramienta y selecciona el archivo JPG con el botón de carga.
2. En el desplegable de formato, elige WebP (también ofrece JPG y PNG).
3. Pulsa el botón de convertir.
4. Aparece un enlace de descarga con el archivo resultante.

Conviene ser explícito sobre qué hace y qué no hace esta herramienta, porque son datos que cambian cuándo te sirve:

• Procesa el archivo en tu equipo. Lee el fichero con la API de ficheros del navegador, lo dibuja en un canvas y exporta el resultado con toBlob. No hay ninguna subida a un servidor: la conversión ocurre en la pestaña. Si cierras la pestaña, no queda nada en ninguna parte.
• La calidad de salida está fijada en un valor alto y no es ajustable desde la interfaz. Para la mayoría de usos va sobrada; si necesitas afinar el peso al kilobyte, la línea de comandos es tu sitio.
• Convierte un archivo cada vez. No hay procesado por lotes. Para catálogos grandes, salta directamente a cwebp o ImageMagick.
• Los metadatos no sobreviven. Al pasar por el canvas, la imagen se convierte en píxeles crudos: EXIF, IPTC y el perfil de color ICC se quedan por el camino. Lo detallo más abajo, porque a veces es justo lo que quieres y a veces es un problema.

Si lo que necesitas es lo contrario —bajar el peso manteniendo el formato— tienes Comprimir imágenes, y si el problema es de dimensiones, Redimensionar imágenes y Recortar. Para la conversión inversa entre los dos formatos clásicos está Convertir PNG a JPG. El listado completo vive en herramientas de archivos y herramientas de imagen.

Puedes ver los resultados de la búsqueda «conversor imagen jpg a webp» en Amazon para comparar precios y opiniones reales.

Qué mirar en cualquier conversor online antes de subir nada

Hay decenas de conversores web y no todos funcionan igual. En vez de una tabla de nombres y límites que caduca en un mes, quédate con las tres preguntas que de verdad los distinguen:

• ¿El archivo sale de tu equipo? Un conversor que trabaja con canvas o con WebAssembly no sube nada. Uno que muestra una barra de progreso de subida y devuelve un enlace, sí. Ninguna de las dos cosas es mala en sí; lo malo es no saber cuál estás usando. Si la imagen contiene datos personales, un documento escaneado o material sujeto a contrato, esa diferencia decide.
• ¿Qué política de borrado tiene si sube el archivo? Debe estar escrita, con un plazo, en la política de privacidad. Si no lo está, asume que se queda.
• ¿Te deja elegir el modo y la calidad? Un conversor que solo tiene un botón te dará un resultado aceptable, no el mejor posible. Para volúmenes pequeños da igual; para un sitio entero, no.

cwebp: la referencia de la línea de comandos

cwebp es el codificador oficial del proyecto libwebp y el que ofrece control completo. Es la opción para lotes, para automatizar y para exprimir el formato.

Instalarlo

Viene en los paquetes que casi siempre se llaman webp o libwebp-tools según la distribución. En macOS con Homebrew es brew install webp; en Debian y Ubuntu, sudo apt install webp; en Windows, Google publica binarios precompilados en la página del proyecto, y también está disponible mediante gestores de paquetes como winget o Chocolatey. Comprueba que funciona con cwebp -version.

El comando mínimo

cwebp -q 80 foto.jpg -o foto.webp

Eso ya hace el trabajo. A partir de ahí, las opciones que realmente merecen conocerse:

Convertir una carpeta entera

En Linux o macOS, un bucle de shell resuelve el lote conservando el perfil de color y limitando el ancho a 1600 píxeles:

for f in *.jpg; do
  cwebp -q 80 -m 6 -mt -metadata icc -resize 1600 0 "$f" -o "${f%.jpg}.webp"
done

En PowerShell, el equivalente:

Get-ChildItem *.jpg | ForEach-Object {
  cwebp -q 80 -m 6 -mt -metadata icc -resize 1600 0 $_.FullName -o ($_.BaseName + ".webp")
}

Fíjate en el -resize. Es la opción que más ahorra y la que más se olvida: servir una foto de 4.000 píxeles de ancho en un hueco de 800 desperdicia tres cuartas partes de los bytes descargados, y ningún códec arregla eso.

Comprobar el resultado

Después de un lote grande, verifica antes de publicar. webpinfo -diag archivo.webp muestra la estructura del contenedor, si es con pérdida o sin pérdida, si lleva alfa y qué bloques de metadatos conserva. Y una comprobación de sentido común que salva disgustos: compara el peso del WebP con el del JPG original y descarta los que hayan engordado. Pasa más de lo que parece con imágenes ya optimizadas.

ImageMagick para lotes grandes

Si ya tienes ImageMagick en el sistema, no necesitas nada más: usa libwebp por debajo, así que la calidad de salida es la misma, y a cambio te da un control mucho mejor del preprocesado (recortes, perfiles, redimensionados con filtros concretos) en un solo comando.

magick foto.jpg -quality 82 foto.webp

Para una carpeta completa, mogrify trabaja en sitio:

magick mogrify -format webp -quality 82 -resize 1600x *.jpg

Las opciones específicas de WebP se pasan con -define:

• -define webp:lossless=true para el modo sin pérdida.
• -define webp:near-lossless=60 para el modo intermedio.
• -define webp:method=6 para apurar la compresión a costa de tiempo.
• -strip elimina todos los metadatos, incluido el perfil ICC. Úsalo con conocimiento de causa.

Una precaución con los perfiles de color: si la foto viene en Display P3 o Adobe RGB y eliminas el perfil sin convertir, el navegador la interpretará como sRGB y los colores saldrán mal. Lo correcto es convertir primero y limpiar después:

magick foto.jpg -profile sRGB.icc -quality 82 -strip foto.webp

Otra utilidad interesante en el mismo terreno es sharp, la biblioteca de Node.js basada en libvips, que es la que usan por debajo muchos frameworks de JavaScript para generar sus imágenes en tiempo de compilación. Si tu sitio se construye con una de esas herramientas, probablemente ya estés generando WebP sin haberlo configurado.

Squoosh, Photoshop y GIMP

Squoosh

Squoosh es la aplicación web del equipo de Chrome para comparar codificadores. Funciona íntegramente en el navegador con WebAssembly, así que la imagen no se sube a ningún sitio, y su valor no está en convertir sino en decidir: te pone el original y el resultado uno al lado del otro con un divisor que arrastras, y te muestra el peso final en tiempo real mientras mueves el control de calidad. Es la forma más rápida de encontrar el punto exacto en el que empieza a notarse la pérdida en tus imágenes. Una vez tengas ese número, aplícalo en masa con cwebp.

Photoshop

Photoshop exporta WebP de forma nativa desde la versión 23.2 (principios de 2022). Lo encuentras en Archivo → Guardar una copia eligiendo WebP en el desplegable de formato, con controles de calidad y la opción de conservar o no los metadatos. En versiones anteriores hacía falta el plugin gratuito WebPShop que publicaba el propio equipo de WebP; si trabajas con una instalación antigua, esa sigue siendo la vía.

GIMP

GIMP exporta WebP desde la rama 2.10 con Archivo → Exportar como y la extensión .webp. El diálogo ofrece calidad, modo sin pérdida, calidad del alfa y casillas independientes para conservar EXIF, IPTC, XMP y el perfil de color. Es, de hecho, una de las interfaces gráficas más completas para el formato, y es software libre.

El explorador de archivos

En macOS, la aplicación Vista Previa exporta a WebP desde el menú de exportar. En Windows, la aplicación Fotos abre WebP sin plugins desde hace varias versiones, aunque su exportación es más limitada. Para una imagen suelta y sin exigencias, son suficientes.

La herramienta correcta depende del volumen. Una imagen: el navegador. Diez imágenes con criterio: Squoosh para calibrar. Diez mil imágenes: cwebp en un script y a otra cosa.

WordPress: cómo se hace bien en 2026

Aquí hay una confusión muy extendida que conviene aclarar. WordPress admite subir y servir archivos WebP desde la versión 5.8, pero eso no significa que convierta nada. Hubo un plan para que el núcleo generase automáticamente versiones WebP de cada JPEG subido, y se retiró antes de publicarse. En una instalación limpia de WordPress, si subes un JPG, se queda en JPG y se sirven miniaturas JPG.

Para conseguir la conversión automática tienes tres caminos:

1. Un plugin oficial del equipo de rendimiento. El proyecto Performance Lab de WordPress incluye un módulo de formatos de imagen modernos que genera versiones WebP de las subidas y las sirve en lugar del JPEG. Es la opción más cercana al núcleo y la que menos capas añade.
2. Un plugin de optimización de imágenes. Imagify, ShortPixel, EWWW Image Optimizer y Converter for Media hacen la conversión y, además, se ocupan de la parte difícil: reescribir el HTML para envolver las imágenes en un elemento <picture>, o configurar las reglas del servidor para servir WebP según la cabecera Accept. Algunos trabajan en su propia nube y otros en tu servidor; comprueba cuál antes de instalar si tienes requisitos de privacidad. Casi todos combinan una cuota gratuita con planes de pago según el volumen, y los precios cambian a menudo, así que consúltalos en su web antes de decidir.
3. Un CDN de imágenes. Delegas la conversión y el redimensionado en la capa de entrega y no tocas la biblioteca de medios. Es la opción más limpia y la que mejor escala.

Dos avisos concretos para WordPress. El primero: WordPress reduce por defecto las imágenes subidas cuyo lado mayor supere los 2.560 píxeles y guarda el original aparte; eso ya te está ahorrando peso antes de hablar de formatos. El segundo: haz copia de seguridad de wp-content/uploads antes de lanzar una conversión masiva. Los plugins que reemplazan archivos en lugar de generar versiones paralelas pueden dejarte sin originales, y algunos temas y constructores guardan rutas absolutas a los ficheros en la base de datos.

Servir WebP sin romper nada: picture, Accept y CDN

Convertir es la mitad del trabajo. La otra mitad es entregar el WebP a quien lo entiende y otra cosa a quien no. Hay dos técnicas y una tercera que las automatiza.

El elemento picture

Es la solución del lado del cliente, y funciona sin tocar el servidor. El navegador recorre las fuentes en orden y se queda con la primera cuyo tipo reconoce; si no reconoce ninguna, usa el <img>:

<picture>
  <source srcset="/img/portada.avif" type="image/avif">
  <source srcset="/img/portada.webp" type="image/webp">
  <img src="/img/portada.jpg" alt="Descripción real de la imagen"
       width="1200" height="630" loading="lazy" decoding="async">
</picture>

Tres detalles que se fallan continuamente. El orden importa: el formato más eficiente va primero, porque el navegador no compara, coge el primero válido. Los atributos van en el <img>, no en los <source>: el alt, el width, el height, las clases y los manejadores de eventos se declaran ahí. Y width y height no son opcionales: son lo que permite al navegador reservar el hueco antes de descargar la imagen y lo que evita que la página salte. Sin ellos estás regalando puntos de CLS.

Se puede combinar con imágenes adaptativas añadiendo srcset con varios anchos y un atributo sizes en cada <source>, para que un móvil no descargue la versión de escritorio.

Negociación por la cabecera Accept

Es la solución del lado del servidor y no requiere cambiar ni una línea del HTML. Los navegadores que soportan WebP lo anuncian incluyendo image/webp en la cabecera Accept de la petición. El servidor comprueba si existe un .webp junto al .jpg solicitado y lo devuelve en su lugar.

La pieza que no se puede olvidar es la cabecera de respuesta Vary: Accept. Sin ella, cualquier caché intermedia —la del CDN, la del proxy corporativo— puede guardar el WebP servido a un navegador moderno y entregárselo después a un cliente que no lo entiende, o al revés. El resultado son imágenes rotas que aparecen y desaparecen sin patrón, y son de las averías más difíciles de diagnosticar porque no se reproducen en tu máquina.

Delegarlo en un CDN de imágenes

Servicios como Cloudflare, Cloudinary, imgix, Netlify o la optimización de imágenes integrada en varias plataformas de despliegue hacen las dos cosas de una vez: reciben el original, generan al vuelo la variante en el formato y el tamaño adecuados para cada visitante, la cachean en el borde y la sirven con las cabeceras correctas. Es la opción con menos piezas móviles y la que evita mantener tres copias de cada imagen en el repositorio. A cambio, es un servicio externo con su coste y su dependencia.

Metadatos: qué se pierde al convertir

Un JPG que sale de una cámara o de un móvil lleva mucho más que píxeles. Al convertir, esa información desaparece salvo que pidas lo contrario, y eso tiene consecuencias que van desde lo estético hasta lo legal.

EXIF

Guarda los datos de la toma: cámara, objetivo, velocidad, diafragma, ISO, fecha, y a menudo coordenadas GPS. También contiene la etiqueta de orientación, que es la que hace que una foto tomada girando el móvil se vea derecha. Los navegadores respetan esa etiqueta al mostrar un <img>. Si conviertes con una herramienta que descarta EXIF pero no rota los píxeles, puedes acabar con fotos tumbadas. Las herramientas basadas en canvas normalmente rotan los píxeles al dibujar y luego tiran el EXIF, con lo que el resultado sale bien; las de línea de comandos suelen mantener los píxeles como están y eliminar la etiqueta, y ahí sí aparece el problema. Compruébalo con una foto vertical antes de lanzar un lote.

La cara buena: eliminar el EXIF es también una medida de privacidad. Publicar fotos con coordenadas GPS de tu casa o del colegio de tus hijos es un descuido frecuente. Para imágenes de web, quitar el EXIF es lo deseable, además de un ahorro de bytes.

Perfil ICC

Describe en qué espacio de color están los números de cada píxel. Si la imagen está en Display P3 o Adobe RGB y le quitas el perfil, el navegador asumirá sRGB y verás los colores apagados o desviados. Este es el metadato que sí conviene conservar siempre que el original no esté ya en sRGB, o alternativamente convertir explícitamente a sRGB antes de eliminarlo. En cwebp se conserva con -metadata icc.

IPTC y XMP

Contienen autoría, crédito, titular de los derechos, pie de foto y palabras clave. En un banco de imágenes o en una redacción, eliminarlos no es un detalle técnico: se está publicando material sin la atribución que exige la licencia. Si trabajas con fotografía de terceros, conserva estos bloques o documenta el crédito en otro sitio.

Antes de lanzar una conversión masiva, decide conscientemente qué metadatos quieres perder. La opción por defecto de la mayoría de herramientas es tirarlos todos, y esa decisión no siempre es la que te conviene.

WebP frente a AVIF y JPEG XL

WebP ya no es el formato moderno; es el formato consolidado. Estas son las alternativas y dónde encaja cada una en 2026.

AVIF: mejor compresión, más coste

AVIF deriva del códec de vídeo AV1 y comprime mejor que WebP, con una ventaja que se hace más evidente cuanto más agresiva es la compresión: a calidades bajas y medias mantiene mucho mejor los degradados y produce menos artefactos de bloque. Además admite HDR, gama amplia y 10 o 12 bits por canal, terreno donde WebP simplemente no juega.

Los costes son reales. Codificar AVIF es notablemente más lento, y eso se nota en un lote de miles de imágenes o en una generación al vuelo. En imágenes muy pequeñas la cabecera de su contenedor puede comerse la ventaja. Y en detalle fino de alta frecuencia —texturas, grano, follaje— hay quien prefiere el resultado de un WebP o incluso de un JPEG bien codificado, porque AVIF tiende a suavizar. La estrategia sensata no es elegir: es servir AVIF primero y WebP después dentro del mismo <picture>, con el JPEG al final.

JPEG XL: excelente y todavía impracticable en la web abierta

JPEG XL es, técnicamente, el más completo de los cuatro. Su función más interesante para quien tiene una biblioteca de fotos es la recompresión sin pérdida de JPEG: puede reenvasar un JPEG existente en un archivo bastante más pequeño y, cuando quieras, reconstruir el JPEG original byte a byte. Eso lo convierte en un formato de archivo excelente, sin la pérdida generacional que sí tiene pasar a WebP.

El problema es de despliegue, no de calidad. El soporte en navegadores está fragmentado: Safari lo incorporó, Chrome retiró la implementación experimental que había tenido y Firefox no lo habilita por defecto. Servir JPEG XL como formato único en una web pública en 2026 significa que una parte de tus visitantes no ve las imágenes. Como formato de almacenamiento interno, en cambio, tiene todo el sentido.

Impacto real en Core Web Vitals

Aquí es donde más se exagera. Convertir a WebP ayuda a las Core Web Vitals, pero solo por una vía concreta, y conviene saber cuál para no esperar milagros.

Los tres indicadores que Google mide son el LCP (Largest Contentful Paint, el tiempo hasta que se pinta el elemento visible más grande, con un umbral de 2,5 segundos en el percentil 75), el INP (Interaction to Next Paint, la latencia de respuesta a las interacciones, con umbral de 200 milisegundos, que sustituyó al antiguo FID en 2024) y el CLS (Cumulative Layout Shift, la inestabilidad visual, con umbral de 0,1).

El formato de imagen no toca el INP en absoluto: eso depende del JavaScript. Toca el CLS solo indirectamente, y lo que de verdad lo arregla es declarar width y height. Su terreno es el LCP, y el LCP se descompone en cuatro tramos:

1. Tiempo hasta el primer byte. Depende del servidor, del hosting y del caché. El formato no interviene.
2. Retraso en la carga del recurso. El tiempo que pasa desde que el navegador puede empezar a pedir la imagen hasta que la pide de verdad. Depende de dónde esté declarada, de si un CSS o un JS bloqueante va delante, y de la prioridad. El formato no interviene.
3. Tiempo de carga del recurso. La descarga en sí. Aquí, y solo aquí, actúa el cambio de formato.
4. Retraso hasta el renderizado. Lo que tarda en pintarse una vez descargada. Depende del hilo principal.

Si tu LCP malo viene de un servidor lento o de una cascada de recursos bloqueantes, puedes convertir todo el catálogo a WebP y ver cómo la métrica no se mueve. El orden correcto de intervención es este:

• Dimensiona. Sirve la imagen al tamaño en que se va a ver, con srcset y sizes para las distintas pantallas. Es lo que más ahorra, con diferencia.
• No hagas lazy loading del elemento LCP. Poner loading="lazy" en la imagen de cabecera es el error de rendimiento más común de los últimos años: retrasa justo la descarga que define la métrica. El lazy es para lo que está por debajo del pliegue.
• Marca la prioridad. fetchpriority="high" en la imagen principal le dice al navegador que la adelante en la cola. Un <link rel="preload"> puede ayudar cuando la imagen la descubre tarde el analizador.
• Reserva el espacio. width y height siempre, y así el CLS no se degrada mientras arreglas el LCP.
• Sirve desde una capa con caché. Un CDN acerca los bytes al visitante y suele importar más que unos kilobytes de diferencia.
• Y entonces convierte a WebP o AVIF. Con todo lo anterior hecho, el cambio de formato es la guinda que redondea el resultado.

Mide con datos de campo, no solo con una herramienta de laboratorio: el informe de experiencia de usuario en Chrome refleja lo que viven tus visitantes reales, con sus dispositivos y sus conexiones, y es lo que se usa para valorar la página.

Errores frecuentes al convertir

Cambiar la extensión del archivo

Renombrar foto.jpg a foto.webp no convierte nada. El contenido sigue siendo un JPEG y ahora, además, el nombre miente. Algunos navegadores lo mostrarán igualmente porque detectan el tipo real por el contenido, pero cualquier proceso que confíe en la extensión fallará.

Convertir con calidad muy baja para presumir de peso

Bajar la calidad a 30 o 40 produce archivos diminutos y fotos con bandas en los cielos y bordes sucios. En una tienda, eso se traduce en producto que parece de peor calidad. El objetivo no es el archivo más pequeño, es el archivo más pequeño que no se nota.

Convertir una y otra vez la misma imagen

Cada pasada por un codificador con pérdida degrada un poco más. Si tienes un flujo automático que recomprime en cada despliegue, acabarás con imágenes visiblemente peores al cabo de unos meses. Convierte una vez desde el original y guarda el resultado.

Borrar los originales

El error más caro y el más difícil de deshacer. El WebP publicado es un derivado. Si mañana necesitas otro recorte, otra resolución, los metadatos o migrar al formato que venga después, tienes que partir del original. La calidad perdida no se recupera.

No comprobar si el archivo ha engordado

Con imágenes ya optimizadas, o con contenido difícil de comprimir, el WebP puede salir más pesado que el JPG. Un script de conversión que no compara y sustituye a ciegas empeora el sitio mientras el informe dice que ha hecho su trabajo. Añade siempre la comparación de tamaños y conserva el menor de los dos.

Convertir vectores a WebP

Un logo en SVG pesa poco, escala a cualquier tamaño sin perder nitidez y se puede recolorear con CSS. Convertirlo a WebP lo congela en una resolución y suele aumentar su peso. Los vectores se quedan como vectores.

Olvidar el fallback y la cabecera Vary

Servir WebP por negociación de contenido sin devolver Vary: Accept genera fallos intermitentes en las cachés intermedias. Y sustituir directamente los JPG por WebP en el HTML, sin <picture> ni negociación, deja sin imágenes a cualquier cliente que no lo soporte, incluidos rastreadores y herramientas de terceros.

Aplicar la misma receta a todo

Una calidad única para fotografía, capturas de pantalla y gráficos con texto da malos resultados en al menos dos de los tres casos. Separa el catálogo por tipo de contenido y usa modo con pérdida para las fotos y sin pérdida o casi sin pérdida para lo demás. Si te interesa profundizar en esa decisión, tienes una comparativa dedicada en JPG, PNG o WebP: cuál usar en cada caso y un desglose de las diferencias entre PNG, JPG y WebP. Para bajar peso sin cambiar de formato, revisa cómo comprimir imágenes sin perder calidad, y si el destino son redes sociales, redimensionar imágenes para redes sociales.

Preguntas frecuentes

¿Convertir JPG a WebP es gratis?

Sí. El formato no tiene licencia de pago y las herramientas de referencia son libres: cwebp (la utilidad oficial de libwebp, con licencia BSD), ImageMagick, GIMP y los conversores que funcionan dentro del navegador. También lo exportan de serie Photoshop y la mayoría de gestores de contenido.

¿Cuánto pesa menos una imagen en WebP que en JPG?

Depende de la imagen y del JPG de partida. Si el JPG viene directo de una cámara o de un móvil, sin optimizar, el recorte suele ser grande. Si el JPG ya pasó por un compresor moderno con una calidad equivalente, la diferencia puede ser pequeña o incluso favorable al JPG. No existe un porcentaje único: hay que medir con tus propias imágenes.

¿Se pierde calidad al convertir un JPG a WebP?

Sí, si eliges WebP con pérdida, porque se decodifica el JPG y se vuelve a codificar. Es una segunda generación de compresión sobre una imagen que ya tenía artefactos. Con calidades altas la diferencia no suele verse a tamaño real, pero existe. Si necesitas conservar cada píxel, usa WebP sin pérdida y asume un archivo mayor.

¿Qué navegadores soportan WebP en 2026?

Todos los navegadores modernos de escritorio y móvil: Chrome, Edge, Firefox, Opera, Samsung Internet y Safari desde la versión 14 (macOS Big Sur e iOS 14). El soporte dejó de ser un problema hace años. Si aún atiendes a navegadores muy antiguos, sirve el WebP dentro de un elemento <picture> con el JPG original como fallback.

¿WebP admite transparencia y animación?

Sí a las dos cosas, y esa es una de sus ventajas frente al JPEG. WebP tiene canal alfa de 8 bits incluso en su modo con pérdida, algo que el JPEG no puede hacer, y su contenedor admite secuencias animadas. Un JPG de origen no tiene transparencia, así que al convertirlo no aparecerá ninguna.

¿Qué metadatos se pierden al convertir a WebP?

Depende de la herramienta. Los conversores que trabajan sobre un canvas del navegador descartan EXIF, IPTC y el perfil ICC. cwebp también los descarta por defecto y hay que pedirle explícitamente que los conserve con la opción -metadata. Perder el perfil ICC de una foto en gama amplia hace que se vea desaturada; perder el crédito de IPTC puede tener consecuencias legales si la imagen es de un tercero.

¿Es mejor AVIF que WebP?

AVIF suele comprimir mejor, sobre todo a calidades bajas y medias, y admite 10 y 12 bits, HDR y gama amplia. A cambio, codifica mucho más lento y su soporte, aunque ya es amplio, llegó después. La combinación habitual en 2026 es ofrecer AVIF primero, WebP después y JPEG como último recurso dentro del mismo elemento <picture>.

¿Puedo usar JPEG XL en una web pública?

Todavía no como formato único. JPEG XL (ISO/IEC 18181) es técnicamente muy bueno y puede recomprimir un JPEG existente sin pérdida y de forma reversible, pero no tiene soporte universal: Safari lo incorporó, Chrome retiró su implementación experimental y Firefox no lo activa por defecto. Sirve para archivo interno, no para servirlo sin fallback.

¿Puedo convertir un JPG a WebP cambiando la extensión del archivo?

No. La extensión es solo una etiqueta del nombre. El contenido sigue siendo un JPEG y el archivo quedará corrupto para cualquier programa que confíe en la extensión. Un WebP real empieza por la firma RIFF seguida de WEBP dentro del propio archivo binario.

¿Convertir a WebP mejora el LCP y el Core Web Vitals?

Ayuda, pero solo en una de las cuatro partes del LCP: el tiempo de descarga del recurso. Si la imagen se sirve con dimensiones enormes para el hueco que ocupa, si lleva loading="lazy" siendo el elemento LCP, si el servidor tarda en responder o si la carga la retrasa un CSS bloqueante, cambiar de formato apenas moverá la aguja. Dimensiona primero, ordena las prioridades después y convierte al final.

¿Sirve WebP para imágenes de correo electrónico o de redes sociales?

Para email, no conviene: varios clientes de correo de escritorio no renderizan WebP y verás un hueco. Para redes sociales y og:image, comprueba el resultado con el depurador de cada plataforma antes de darlo por bueno; el JPG o el PNG siguen siendo la opción segura para la imagen de previsualización.

¿Debo borrar los JPG originales después de convertir?

No. Guarda siempre el original en su máxima calidad. El WebP publicado es un derivado; si mañana aparece un formato mejor, o necesitas otro recorte, otra resolución o los metadatos, tendrás que partir del original. Reconstruir calidad desde un archivo ya comprimido no es posible.

Resumen para llevarse

Convertir de JPG a WebP es una buena idea para casi todas las imágenes que sirves por web, y una mala idea para casi todo lo demás. Usa la herramienta del navegador para archivos sueltos, cwebp o ImageMagick para lotes, y Squoosh para decidir a qué calidad trabajar. Sirve el resultado con <picture> o con negociación por Accept y Vary, conserva el perfil de color si tus fotos no están en sRGB y guarda siempre el original. Y recuerda el orden: dimensionar la imagen y ordenar las prioridades de carga rinde más que cambiar de formato. El formato es el último paso, no el primero. Si quieres seguir el hilo, tienes el panorama completo en nuestra guía de conversores online técnicos gratis.