Convertir HEIF a WebP

Los portales inmobiliarios, los marketplaces y los gestores de contenidos validan lo que subes contra una lista cerrada de extensiones, y HEIF casi nunca está en ella. La razón no es capricho: en cuanto aceptan una imagen tienen que generar una miniatura, tres tamaños para móvil y una vista previa en el editor, y con un formato que la mitad de los navegadores no dibuja no pueden hacer ninguna de las tres cosas con garantías.

La consecuencia práctica es que la conversión te toca a ti y conviene hacerla antes de subir, no después. Así decides tú el ancho y la calidad; si lo dejas en manos del recodificador automático del portal, ese trabaja con lo que le hayas entregado y no siempre con buen criterio.

WebP define dos modos, uno con pérdida y otro sin ella. Esta conversión escribe siempre el primero, con el valor de calidad que elijas y 82 por defecto. Conviene decirlo pronto porque mucha gente asocia «formato moderno» con «sin pérdida», y aquí no es el caso.

Para una fotografía esa es la decisión correcta por bastante margen: un WebP sin pérdida de una imagen de cámara ocupa varias veces más y no recupera nada, porque el HEIF ya descartó lo que descartó antes de que tú llegaras. Si de verdad necesitas una copia exacta de la foto, el destino honesto es PNG, no WebP.

La calidad va de 1 a 100 y arranca en 82. Para fotos que se van a ver dentro de una página, ese punto está bien elegido: el detalle aguanta al tamaño al que el navegador va a dibujar la imagen y el archivo es una fracción de lo que costaría cualquier copia exacta. Bajar a la franja de los sesenta ahorra bytes de verdad y empieza a notarse en los bordes y en las superficies lisas.

Recuerda que es la segunda compresión que sufre la imagen. La cámara la comprimió al escribir el HEIF y aquí se comprime lo que quedó de aquello. Una pasada más a 82 no la va a ver ningún visitante, pero sí es motivo para convertir siempre desde el HEIF original y no desde un WebP anterior.

De todos los controles de esta página, el del ancho máximo es el que más rinde para un uso web. Reducir una foto de 4.032 píxeles a 1.600 deja al codificador aproximadamente una sexta parte de los datos antes siquiera de empezar a comprimir, y 1.600 ya es generoso para una imagen dentro de un artículo en pantalla grande.

Servir la foto a resolución completa y dejar que el navegador la encoja es el error de peso de página más repetido que existe: el visitante paga todos esos píxeles y ve como mucho una quinta parte. Si necesitas varios tamaños para un juego responsive, convierte el HEIF varias veces con anchos distintos en lugar de reescalar el WebP después.

Un WebP no puede medir más de 16.383 píxeles de lado. Es una propiedad del formato, no de este conversor, y no hay ajuste que la esquive. Una foto de doce o de cuarenta y ocho megapíxeles queda lejísimos de ese número en ambas dimensiones, así que en el uso normal no aparece nunca.

Donde sí aparece es en las panorámicas. El modo panorámico del móvil cose una imagen muy ancha y muy baja, y esas pasan de dieciséis mil píxeles de largo con facilidad. Para una de ellas, fija un ancho máximo antes de convertir, que además es lo que querías hacer de todas formas: ninguna página muestra una imagen a ese ancho.

Los dos formatos tienen canal alfa, así que un recorte con fondo vacío llega intacto y puede colocarse sobre una franja de color sin que aparezca un rectángulo blanco alrededor.

Lo que no cruza es el resto del contenedor. Un archivo HEIF puede llevar varias imágenes dentro —una ráfaga, los fotogramas de una foto en movimiento, una secuencia de horquillado— y de ahí se toma solamente la primera. Las demás no se escriben en ningún sitio ni hay opción que llegue a ellas. Y hay un segundo recorte menos visible: el descodificador entrega ocho bits por canal, así que un HEIF grabado con más profundidad llega a la salida ya reducida a esa escala. Para una foto destinada a una página web es irrelevante; para material que después vaya a corregirse de color, el original sigue siendo el sitio del que hay que partir.

El WebP que sale no contiene EXIF ni XMP. No se ha filtrado nada: la conversión descodifica la imagen a píxeles y la vuelve a codificar, y por ese paso los metadatos no tienen ruta.

En una página sobre publicar, es el dato más útil que hay aquí. Una foto hecha con el móvil suele llevar latitud y longitud con precisión de portal, y un anuncio inmobiliario, una ficha de producto de segunda mano o una entrada de blog que la lleven están publicando una dirección concreta. Algunas plataformas la quitan al subir y otras no; convertir antes te libra de tener que averiguar cuál de las dos te ha tocado.

AVIF comprime la misma imagen a menos bytes con calidad visible equivalente, y su soporte es más reciente. Esa es toda la comparación, y se resuelve sola según cómo sirva las imágenes tu sitio.

Si subes un archivo y ese mismo archivo se entrega a todo el mundo, la respuesta es WebP: sin negociación, sin alternativa que mantener, sin nada que probar. Si tu capa de entrega sabe ofrecer AVIF a quien lo anuncia y WebP al resto, entonces AVIF merece el paso extra y tiene página propia. Elegir AVIF como formato único porque es más nuevo es la forma habitual de que a alguien le salga una imagen rota.

La conversión va en una sola dirección. Leemos HEIF y no lo escribimos, y no es una funcionalidad pendiente: codificar HEIF exige x265, cuyo licenciamiento es incompatible con lo que un sitio estático puede cumplir. Por eso ni HEIC ni HEIF aparecen como destino en ninguna página.

Eso convierte al HEIF en el original y al WebP en un derivado. Guárdalos con esa jerarquía en la cabeza: el archivo que no se puede volver a fabricar es el que no se borra.

Tanto el descodificador de HEIF como el codificador de WebP se ejecutan dentro de la pestaña, sobre tu propio procesador. No hay subida, ni cola, ni cuenta, y el archivo no llega a existir en el disco de nadie más: para fotos de producto sin publicar o de personas que aún no han dado su permiso, esa es la diferencia que cuenta.

El plan gratuito acepta hasta 100 MB por archivo, cifra a la que no se acerca ninguna foto de móvil, y admite cien archivos por tanda. Cuando hay dos convertidos aparece la descarga conjunta en ZIP, así que preparar treinta imágenes de una galería es una descarga y no treinta. Si sueltas más de cien de golpe, los que sobran se quedan fuera del lote: conviene contarlos antes y no dar por hecho que ha entrado la carpeta entera. Tampoco hay recuento diario que se agote, porque una conversión que ocurre en tu equipo no nos cuesta nada y no hay ningún motivo para racionarla.

La mayoría de gestores de contenidos vuelve a codificar lo que reciben: generan miniaturas, montan un juego responsive y con frecuencia recomprimen el original con ajustes que no puedes ver. Tu WebP es, en ese caso, la entrada de otro codificador y no el archivo que descarga el visitante.

Es un argumento a favor de convertir a las dimensiones correctas y con una calidad generosa, en vez de apretar el archivo tú. Una imagen ya machacada a calidad 55 y luego recomprimida por la plataforma acumula los dos juegos de artefactos; una a 82 le da al sistema algo limpio con lo que trabajar. Y si tu gestor guarda el original tal cual, entonces mandan los números de esta página.

Dos cosas, y ninguna lleva tiempo. Las dimensiones reales del resultado, porque una carpeta de fotos reunida durante años mezcla capturas de móviles distintos y el ancho máximo actúa sobre cada una a partir de lo que traía. Y el peso final por archivo, que es el número por el que se hizo todo esto y el que más se da por supuesto.

Si la galería va a un portal con límite de tamaño por foto —muchos lo tienen, y suele estar en pocos megabytes—, mira el archivo más grande de la tanda y no el primero. Un lote se rechaza entero por su peor elemento, y descubrirlo al subir el número veintiocho es la forma cara de enterarse.