Cómo funciona
Qué ocurre con tu archivo y cómo elegir los ajustes
Cada decodificación, redimensionado y codificación ocurre en tu dispositivo. Esto es lo que hace cada paso, qué cambia cada ajuste y dónde se detiene la herramienta.
1. Tu navegador lee el archivo
La zona de arrastre entrega el archivo a la File API y después a un Web Worker de este dispositivo. No hay ningún paso de subida.
2. Un códec trabaja sobre los píxeles
Los módulos WebAssembly construidos a partir de MozJPEG, el códec PNG de Squoosh, oxipng, libwebp y libavif decodifican y codifican la imagen fuera del hilo principal, y los ports de Rust se encargan del redimensionado, así que la página sigue siendo utilizable. Cada módulo lleva su propia licencia, y la página de créditos los lista.
3. Descargas el resultado
Cada archivo terminado tiene su propio enlace de descarga, su tamaño antes y después y una vista previa de lo que vas a obtener.
Dónde ocurre el trabajo
Tu archivo nunca llega a un servidor, y tampoco el resultado. La página lee el archivo con la File API, que da al navegador un puntero a bytes que ya están en tu disco; no los sube. Esos bytes van a un Web Worker, un hilo en segundo plano, así que un lote largo no congela la página que estás leyendo. Dentro de ese worker, los códecs convierten tu imagen en píxeles de 8 bits sin más, la redimensionan si se lo has pedido y codifican el resultado en el formato que has elegido.
Los códecs son módulos WebAssembly construidos a partir de MozJPEG, el códec PNG de Squoosh, oxipng, libwebp y libavif, más ports de Rust para el paso de redimensionado. La página de créditos lista cada uno con su propia licencia, porque la licencia de un paquete envoltorio no es la del códec. Un módulo se descarga de este sitio la primera vez que usas su formato, y por eso la primera conversión de un formato es más lenta que las siguientes. No se descarga nada de ningún otro sitio, y ninguna petición lleva tu archivo.
Cómo elegir la calidad
La calidad es un número entero del 1 al 100 y empieza en 75. Se aplica a JPEG, WebP y AVIF, los tres con pérdida: un número más bajo gasta menos bits en la imagen y uno más alto gasta más. El PNG es sin pérdida, así que ignora el ajuste por completo, y la herramienta lo dice mientras el PNG esté seleccionado.
Ninguno de los dos extremos es gratis. En el 1 la imagen conserva su forma pero pierde detalle, y adónde va primero ese detalle depende de la imagen y del codificador, así que esta página no promete ningún orden. En el 100 el archivo es grande y aun así no es del todo el original, porque el codificador reconstruye la imagen a partir de una descripción comprimida de ella. Si no sabes por dónde empezar, déjalo en 75 y compara las dos vistas previas que muestra cada fila terminada: la de la izquierda es el archivo que elegiste, la de la derecha es lo que vas a descargar.
Cómo elegir un tamaño
El redimensionado está apagado hasta que lo actives. Por ancho, la salida tiene ese número de píxeles de ancho y conserva las proporciones de la imagen, así que una foto 3:2 con un ancho de 1280 sale 1280 por 853. Por porcentaje, las dos dimensiones pasan a ser esa parte del original. El campo de porcentaje se detiene en 100, así que el modo porcentaje no puede ampliar una imagen; un ancho que pongas por encima del original sí la amplía, lo cual rara vez hace que un archivo sea más pequeño y por eso el campo de porcentaje es el más seguro de los dos.
Si tu cámara guardó una rotación en el archivo, esa rotación se aplica a los píxeles antes de que ocurra nada más, así que una foto hecha en vertical sale con la orientación correcta. Las cuatro orientaciones que incluyen un cuarto de vuelta, las EXIF 5 a 8, intercambian el ancho y el alto, así que una foto etiquetada como 6 sale 400 por 600 desde un archivo cuyos números son 600 por 400. Las otras cuatro dejan los dos números como estaban: sin cambio alguno, las dos que son espejo, y el giro de 180 grados, que gira la imagen de lado sin hacerla más alta ni más ancha.
Un formato de entrada no lleva esa rotación a la herramienta en absoluto: el bloque EXIF de una entrada AVIF no se lee, así que un archivo AVIF que guarda una orientación se usa tal y como está almacenado, con sus dimensiones tal y como las declara su archivo.
Alcanzar un límite de tamaño
Los formularios y los servidores suelen querer un archivo por debajo de cierto número de kilobytes, y no solo más pequeño. El campo de tamaño objetivo toma ese número en KiB, que son 1024 bytes y no 1000, y la herramienta trabaja hacia él: si la primera codificación está por encima del número, baja la calidad, hasta el 1, hasta que el archivo quepa, y si la primera codificación sale muy por debajo, sube la calidad desde tu ajuste, nunca por encima de 100, buscando la calidad más alta que todavía cabe. La fila te dice después si el archivo que recibes está en el objetivo o por debajo.
Tres límites honestos. La búsqueda solo puede gastar calidad, y solo la mitad hacia arriba está limitada por tu ajuste, así que una imagen que siga por encima del objetivo con la calidad en 1 no lo alcanzará, y lo que recibes entonces es la codificación con calidad 1. En la otra dirección, un objetivo por encima de lo que la calidad 100 puede alcanzar para esa imagen no se puede llenar haciendo el archivo más grande, porque la escala se detiene en 100: recibes el archivo más grande que el formato produjo, que sigue por debajo de tu número, y la fila informa el objetivo como alcanzado, porque el archivo está por debajo del techo. Y el PNG ignora el ajuste de calidad, así que la búsqueda no tiene nada que gastar ahí: una salida PNG recibe igualmente una segunda pasada por oxipng, que puede devolver menos bytes que la primera codificación, de modo que un objetivo en PNG que la primera codificación se pasó puede cumplirse igualmente, y uno que ninguna de las dos pasadas puede alcanzar se informa como no alcanzado.
Un objetivo es un techo con un suelo en el 95 por ciento de ese techo, no un tamaño al que apuntar. La calidad se mueve en números enteros, y un paso puede saltar por encima de toda la banda, así que la búsqueda apunta a la banda y cae dentro cuando un paso cae dentro, y devuelve la codificación más cercana por debajo de tu objetivo cuando ningún paso lo hace. No promete un tamaño exacto ni un archivo dentro de un 5 por ciento de tu número, y el número que informa es si el archivo que está a punto de entregarte está en tu objetivo o por debajo.
Esa última frase es lo que decide el veredicto. Los bytes se cuentan después de haber escrito dentro cualquier bloque EXIF, así que si pides conservar los metadatos y el bloque empuja el archivo por encima de tu objetivo, la fila dice que el objetivo no se alcanzó aunque la codificación por sí sola estuviera por debajo. Nunca te dirán que se cumplió un límite cuando el archivo que descargas lo supera.
Cuándo se rechaza un archivo
Los dos límites se comprueban en momentos distintos, y la diferencia conviene conocerla. Un archivo de más de 32 MiB se rechaza solo por su tamaño, antes de leer sus bytes, así que no cuesta nada. Un archivo de más de 40.000.000 de píxeles tiene que leerse entero primero, porque su número de píxeles solo se conoce una vez analizada su cabecera, así que una imagen demasiado grande se lee y luego se rechaza antes de que nada decodifique sus píxeles.
La fila nombra el límite por el que se rechazó, de cualquier manera. Un archivo rechazado nunca detiene el lote: todos los demás archivos que elegiste terminan igualmente. Ninguno de los dos límites depende del equipo que estés usando. Son números fijos, no una lectura de memoria, así que un ordenador más rápido o más pequeño no los sube. Lo que sí los cambia es la entrada: recorta la imagen, redimensiónala en otro sitio o reparte el trabajo, y después vuelve a elegir los archivos (elegir de nuevo reemplaza la lista).
Una entrada que la herramienta no puede decodificar, porque está dañada o truncada, recibe una fila que lo dice en el mismo sitio. Un archivo cifrado no se puede abrir aquí: no hay ningún campo de contraseña y ninguna parte de tu archivo se envía a ninguna parte para desbloquearlo.
Un fallo tiene que ver con el navegador y no con la imagen. Si el worker que convierte un archivo no se puede iniciar, o muere a mitad del trabajo, ese archivo recibe una fila que dice que el navegador no pudo ejecutar el motor de imágenes, y ese worker no toma más archivos. Los demás workers siguen con el resto de la cola, y las filas que ya habían terminado conservan sus resultados. Si fallan todos los workers, entonces cada archivo que no había empezado ya recibe esa misma fila en lugar de esperar: la conversión termina con una respuesta para cada uno en vez de quedarse atascada en los archivos a los que no llegó ningún worker. Un archivo que solo falla al decodificarse o codificarse no es este caso: ese es el error de esa fila, y el worker que lo informó sigue con el archivo siguiente. Prueba con una versión actual de Chrome, Firefox, Edge o Safari.
¿Listo para probarlo con tus propias imágenes?
La herramienta está en la página de inicio. Suelta unos archivos y compara los tamaños uno al lado del otro.