Un compresor de GIF que construye de verdad cada nivel de calidad para que elijas
Este compresor de GIF reescribe un GIF animado para que el archivo pese menos. Construye de verdad los cinco niveles de compresión, desde «sin pérdida» hasta «máximo», y muestra el tamaño de cada uno en una barra. Por ejemplo, el GIF de ejemplo creado a partir de un vídeo (360 × 240, 32 fotogramas, 1,70 MB) quedó en 947 KB (−44,1%) con el nivel Medio, y la grabación de pantalla de ejemplo (400 KB) bajó a 87 KB (−78,4%) solo con el nivel Sin pérdida, que no cambia ni un píxel.
Arrastra la línea de la imagen para comparar el original y el resultado en el mismo punto, y después pausa y avanza fotograma a fotograma. El mapa de fotogramas de abajo muestra cuántos bytes ocupa cada fotograma, así que se ve qué escenas pesan más. Si eliges un tamaño objetivo, la herramienta escoge el nivel más ligero que lo cumple y, si aun así se pasa, reduce el ancho hasta que el archivo cabe. Para comprimir un GIF no hace falta subirlo a ningún servidor: todo ocurre dentro de este navegador.
Cuándo usarlo
- Para subirlo a un sitio con límite de tamaño: según GitHub Docs, las imágenes y los GIF que se adjuntan a los comentarios de incidencias y pull requests pueden pesar hasta 10MB. Si la grabación de pantalla que quieres adjuntar a una incidencia es mayor, elige 10 MB como tamaño objetivo. Los chats, los foros y el correo tienen cada uno su propio límite de adjuntos, así que consulta la página donde vas a subirlo y apunta un poco por debajo.
- Cuando un blog o una ficha de producto cargan despacio: los GIF animados hechos a partir de un vídeo, como un producto en uso, pesan fácilmente varios MB cada uno, y una página con varios tarda en abrirse en el móvil. Los niveles Ligero y Medio, que dejan la imagen casi como estaba, suelen reducir mucho el tamaño por sí solos.
- Para meter una grabación de pantalla en un documento: en una grabación de tutorial casi toda la pantalla está quieta y solo se mueve una parte pequeña. El nivel Sin pérdida reescribe solo lo que cambia, así que este tipo de GIF adelgaza mucho sin perder calidad.
- Para volver a subir un GIF que descargaste: los GIF que se han guardado muchas veces suelen llevar la pantalla entera y una paleta completa en cada fotograma. Si el archivo reconstruido saliera más grande que el original, esta herramienta te devuelve el original, así que probar no te cuesta nada.
Cómo se usa
- Suelta el GIF en el área de trabajo o pulsa «Elegir un GIF». Si lo has copiado, también puedes pegarlo con Ctrl+V. Se abre un GIF cada vez, de hasta 50 MB.
- En cuanto se abre, se construye el resultado con el nivel Medio y después se van construyendo los otros cuatro, de modo que la barra de compresión se llena con tamaños reales. Pulsa un nivel para ver ese resultado.
- Si el sitio donde vas a subirlo tiene un límite, elige un tamaño objetivo (de 1 a 15 MB o el que quieras). Se selecciona el nivel más ligero que lo cumple y, si ni siquiera el nivel Fuerte llega, se reduce el ancho hasta que quepa.
- Si quieres, cambia el ancho (original, 75 %, 50 % u otro) y los fotogramas (todos, o 1 de cada 2 a 4). Abre «Elegir a mano» para fijar tú mismo el número de colores y la pérdida.
- Arrastra la línea de la imagen para comparar el original con el resultado. Pulsa «Pausa» o el mapa de fotogramas para detenerte en uno, y pasa de uno en uno con los botones de anterior y siguiente o con las flechas del teclado.
- Pulsa «Guardar GIF». El tamaño se añade al final del nombre del archivo (por ejemplo, gato-gracioso-947kb.gif).
En qué se diferencian los cinco niveles de compresión
Cada nivel que subes permite que más píxeles difieran del original. Los tamaños de la tabla se midieron reduciendo de verdad los dos ejemplos con esta herramienta. El PSNR expresa en decibelios la diferencia de píxeles entre el original y el resultado: cuanto más alto, más se parece al original. En el ejemplo de GIF animado, «Medio» (unos 35 dB) apenas se distinguía del original incluso ampliado al doble y lado a lado, mientras que «Fuerte» y «Máximo» (por debajo de 30 dB) llenaban el fondo blanco de puntitos y volvían ásperas superficies lisas como las manzanas y la pera. El mismo número puede verse distinto en otro GIF, así que tómalo solo como orientación.
| Nivel | Qué hace | GIF de vídeo (1,70 MB) | Grabación de pantalla (400 KB) |
|---|---|---|---|
| Sin pérdida | Reescribe solo los píxeles que cambian, une escenas idénticas y conserva los colores originales | 1,70 MB · igual que el original (se mantiene el original) | 87 KB · igual que el original |
| Ligero | Trata como iguales los colores muy parecidos al comprimir (LZW con pérdida débil) | 1,12 MB · 39,6 dB | 65 KB · 52,1 dB |
| Medio | LZW con pérdida media y deja intactos los píxeles parecidos | 947 KB · 34,9 dB | 63 KB · 49,9 dB |
| Fuerte | 128 colores más LZW con pérdida amplia | 692 KB · 29,6 dB | 48 KB · 41,0 dB |
| Máximo | 64 colores más LZW con pérdida máxima | 552 KB · 27,0 dB | 46 KB · 39,9 dB |
- El GIF de vídeo no se redujo sin pérdida: en este ejemplo la imagen se acerca despacio y cada píxel lleva ruido, así que cambian todos los píxeles de todos los fotogramas. Al no haber nada sin cambiar que omitir, el resultado sin pérdida no salió más pequeño que el original y la herramienta te entrega el original.
- En la grabación de pantalla, el nivel Sin pérdida hizo casi todo: el original guarda la pantalla entera en cada fotograma, pero solo cambian los números, el gráfico y el cursor. Al escribir solo esas partes se llegó a −78,4%, y los niveles con pérdida ahorran apenas unos KB más.
- Desde Fuerte se reducen los colores: bajar a 128 o 64 colores produce escalones (bandas) en las zonas suaves, como el cielo o una tela oscura, y empiezan a verse las rayas horizontales del LZW con pérdida. Por eso esas barras llevan rayado y, al buscar un tamaño objetivo, nunca se elige Máximo automáticamente.
Por qué un GIF puede adelgazar sin perder calidad
La especificación del GIF (GIF89a) hace que el descriptor de imagen de cada fotograma indique su posición izquierda y superior en la pantalla y su ancho y alto. Por eso un fotograma puede ser un rectángulo pequeño y no la pantalla entera. Además, cada fotograma puede declarar un índice de color transparente y, según la especificación, un píxel con ese índice no modifica la pantalla, de modo que se sigue viendo la imagen anterior. Esta herramienta aprovecha ambas ideas para reducir el tamaño sin cambiar ningún píxel.
- Un rectángulo alrededor de lo que cambia: solo se guarda el rectángulo más pequeño que contiene todos los píxeles distintos de los del fotograma anterior. En una grabación donde solo se mueve el cursor, un fotograma queda en un rectángulo del tamaño de una miniatura.
- Los píxeles sin cambios dentro del rectángulo pasan a transparentes: dentro de ese rectángulo, los píxeles que no cambian se vacían con el índice transparente. Las tiradas largas del mismo índice se comprimen muy bien con LZW. Aun así, cuando los cambios son pequeños y dispersos, a veces sale más pequeño usar los colores originales, de modo que para cada fotograma se comprimen dos o tres variantes y se usa la más pequeña.
- Las escenas idénticas solo suman tiempo: un fotograma con exactamente los mismos píxeles que el anterior no se guarda y su tiempo de visualización se suma al del fotograma previo. La duración total no cambia.
- Los colores se quedan como estaban: si entre todos los fotogramas suman 255 colores o menos, los colores originales se escriben en una paleta global única. Si hay más, cada fotograma lleva una paleta con solo los colores usados en su rectángulo.
Para un GIF en el que las zonas transparentes deben volver a ser transparentes (por ejemplo, una pegatina animada sobre fondo transparente), el fotograma anterior se cambia a «restaurar al fondo» (método de eliminación 2), de modo que esa zona se vacía antes de dibujar el siguiente. Las pruebas de esta herramienta compararon los resultados con los originales píxel a píxel, fotograma a fotograma.
Qué descarta la compresión con pérdida
El GIF comprime los índices de los píxeles con LZW (Welch 1984). Guarda en un diccionario las secuencias de índices que ya han aparecido y, cuando vuelve a salir la misma secuencia, escribe un único código del diccionario. Los códigos tienen como máximo 12 bits, así que el diccionario admite hasta 4.096 entradas. El LZW con pérdida, al buscar una secuencia en el diccionario, acepta también píxeles cuyo color solo se diferencia un poco, y así puede seguir con una secuencia más larga. Es la misma idea que la opción --lossy de gifsicle: cuanto más largas son las secuencias, menos códigos hay que escribir y menos pesa el archivo.
- Qué cambia: cada píxel pasa a un color parecido pero algo distinto. La diferencia se traslada al píxel siguiente para que el color medio se mantenga, pero en los niveles altos aparecen rayas horizontales largas. Funciona bien en GIF de vídeo con aspecto de foto y rinde poco en grabaciones de pantalla de colores planos.
- Dejar intactos los píxeles parecidos: en un GIF hecho a partir de un vídeo, incluso un fondo quieto cambia un poco en cada fotograma por culpa del ruido. En los niveles con pérdida, un píxel cuyo color es muy próximo al que ya está en pantalla se da por no modificado y se vacía con el índice transparente. La comparación se hace siempre con el color original del fotograma actual, así que las diferencias no se acumulan de un fotograma a otro.
- Las zonas transparentes se respetan: ni siquiera en los niveles con pérdida se cambian entre sí los píxeles transparentes y los opacos. Un GIF de tipo pegatina conserva su contorno.
Qué pasa al reducir el número de colores
La paleta de un GIF tiene un tamaño que es potencia de dos (2, 4, 8 … 256) y admite como máximo 256 colores. Al bajar a 128 o 64 colores hacen falta menos bits por cada índice de píxel y el archivo se encoge. Esta herramienta elige los colores con median cut (Heckbert 1982) a partir de píxeles tomados por igual de todos los fotogramas, y hace que todos usen la misma paleta global. Los colores no cambian de un fotograma a otro, así que hay menos parpadeo y ningún fotograma necesita su propia paleta.
- Los dibujos de colores planos, los iconos y las grabaciones de pantalla usan pocos colores, así que incluso con 64 colores el cambio es pequeño.
- En las fotos con degradados suaves, como cielo, piel o sombras, pueden verse bandas desde los 128 colores. No se usa tramado (dithering): hace que el patrón de puntos sea distinto en cada fotograma, con lo que aumentan los píxeles que cambian y el archivo crece.
- En un GIF largo con muchos cambios de escena, cada escena tiene colores distintos, y con una sola paleta global algunas escenas pueden quedar más ásperas. En esos casos es mejor quedarse en Medio o por debajo y reducir el ancho.
Reducir el ancho y el número de fotogramas
Al reducir el ancho, el alto baja en la misma proporción, de modo que el número de píxeles disminuye con su cuadrado: un ancho del 75 % deja el 56 % de los píxeles, y uno del 50 %, el 25 %. Al aclarar los fotogramas se conserva 1 de cada 2, y el tiempo de cada escena eliminada se suma al fotograma que se queda, así que la duración total no cambia. La tabla de abajo mantiene el nivel Medio y cambia solo el tamaño y los fotogramas. El porcentaje entre paréntesis es la reducción respecto al original.
| Qué se cambió | GIF de vídeo | Grabación de pantalla |
|---|---|---|
| Sin cambios (Medio) | 360 × 240 · 947 KB | 560 × 350 · 63 KB |
| Ancho 75 % | 270 × 180 · 524 KB (−69,1%) | 420 × 263 · 43 KB (−89,3%) |
| Ancho 50 % | 180 × 120 · 257 KB (−84,8%) | 280 × 175 · 25 KB (−93,9%) |
| 1 de cada 2 fotogramas | 16 fotogramas · 475 KB (−72,0%) | 25 fotogramas · 38 KB (−90,6%) |
| 1 de cada 3 fotogramas | 11 fotogramas · 315 KB (−81,4%) | 17 fotogramas · 29 KB (−92,8%) |
El GIF de vídeo se redujo casi en proporción al número de píxeles al bajar el ancho y los fotogramas. La grabación de pantalla cambia solo en una zona pequeña, así que reducir el ancho a la mitad ahorra menos que en el vídeo. Una grabación con texto pequeño puede volverse ilegible al reducir el ancho, de modo que conviene probar antes con otro nivel que con otro tamaño.
Los retardos de los fotogramas del GIF se cuentan en centésimas de segundo. El código fuente de WebKit, el motor de Safari, contiene un comentario que dice que, como Firefox, muestra con 0,1 segundos los fotogramas con un retardo de 0,01 segundos o menos. Por eso, al unir fotogramas, esta herramienta cuenta como 0,1 segundos un fotograma escrito con 0 o con 0,01 segundos antes de sumar. Los retardos de los fotogramas que no se unen se dejan exactamente como en el original.
Cómo se alcanza un tamaño objetivo
- Con el ancho y los fotogramas actuales, la herramienta construye de verdad los niveles desde Sin pérdida hasta Fuerte y elige el primero (el más ligero) que queda igual o por debajo del objetivo. Si el original ya cumple el objetivo y Sin pérdida no lo reduce, se devuelve el original tal cual.
- Si ni siquiera Fuerte llega, se mantiene Fuerte y se reduce el ancho. Como el tamaño es aproximadamente proporcional al número de píxeles, la herramienta estima el siguiente ancho, lo construye de verdad, lo mide y repite varias veces hasta encontrar el mayor ancho que cabe.
- Con el ancho encontrado se vuelven a medir los cinco niveles y se muestra el más ligero que cumple. En el área del resultado se indica qué se cambió, por ejemplo «Para llegar a 2 MB, el ancho ha pasado de 360 a 300px».
- Si pulsas un nivel tú mismo, se usa ese nivel tal cual, y si supera el objetivo te lo indica con texto en rojo.
Los tamaños se cuentan con 1 KB = 1.000 bytes y 1 MB = 1.000.000 de bytes (prefijos del SI). Las cifras mostradas están redondeadas hacia arriba, así que cuando pone «dentro de 2 MB», los bytes reales también son 2.000.000 o menos. Si el sitio donde subes cuenta en MiB (1.048.576 bytes), con la misma cifra te sobra un poco más de margen.
Cómo leer el mapa de fotogramas
El mapa de fotogramas avanza a lo largo del tiempo y cada celda es un fotograma original. El ancho de la celda es el tiempo que ese fotograma está en pantalla, así que una última escena que se queda mucho rato se ve ancha. La barra gris son los bytes que ocupa ese fotograma en el original y la barra naranja, los que ocupa en el resultado. La altura usa una escala de raíz cuadrada para que se vean también los fotogramas pequeños.
- El primer fotograma es el mayor: tiene que dibujar la pantalla entera, así que siempre es grande. En la grabación de pantalla de ejemplo, las barras naranjas bajan mucho después del primer fotograma porque solo se guardan las partes que cambian.
- Las celdas rayadas son fotogramas que no están en el resultado como fotograma propio: o eran idénticos al anterior y solo se unió su tiempo, o se descartaron al aclarar los fotogramas. Durante ese tiempo se ve el fotograma anterior.
- Donde las barras se disparan, cambió la escena: en un GIF de vídeo, una celda con una barra de pronto más alta es una escena en la que cambió toda la imagen. Si ese tramo es largo, aclarar los fotogramas ayuda mucho.
Si pulsas el mapa, te detienes en ese fotograma y la imagen muestra el original y el resultado en el mismo instante. Con las flechas del teclado avanzas de uno en uno y puedes buscar las escenas donde la pérdida se nota.
Errores frecuentes
- Un archivo al que solo se le cambió la extensión a .gif: un PNG, JPG o WebP con otro nombre no es un GIF y no se abre. Para convertir varias fotos en una animación usa el creador de GIF, y para convertir un vídeo en GIF, el conversor de vídeo a GIF.
- Creer que la mitad de ancho es la mitad de peso: los píxeles se quedan en la cuarta parte, pero el tamaño del archivo depende de cuánto cambia entre fotogramas. Como muestra la tabla de arriba, un vídeo y una grabación de pantalla se reducen de forma distinta.
- Creer que quitar fotogramas lo acelera: el tiempo de los fotogramas eliminados se suma a los que quedan, así que la duración es la misma. Solo se pierde fluidez en el movimiento.
- Comprimir otra vez un GIF ya comprimido: si reduces un GIF que ya se redujo con un nivel con pérdida, la pérdida se acumula. Si conservas el original, es más limpio ir del original al nivel que quieras en un solo paso.
- Esperar que «Sin pérdida» siempre lo haga más pequeño: un GIF que ya está bien comprimido no adelgaza al reescribirlo. En ese caso esta herramienta devuelve el original y lo indica en el área del resultado.
- Confundir MB con MiB: un límite de «10MB» puede significar 10.000.000 de bytes o 10.485.760 bytes según el servicio. Apuntar un poco por debajo del límite es lo más seguro.
Límites
- Un GIF cada vez, de hasta 50 MB, 1.000 fotogramas y ancho × alto × fotogramas de 150 millones de píxeles. El ancho y el alto pueden llegar cada uno a 8.000px. Estas cifras no son límites del formato GIF, sino un margen elegido para que esta herramienta no bloquee el navegador.
- Los tamaños de las tablas se midieron el 2026-10-21 con el motor de esta herramienta. Con el mismo motor se obtiene el mismo tamaño en cualquier navegador, pero pueden cambiar si se modifica el motor.
- La calidad de cada nivel no se decide solo con cifras como el PSNR. El mismo nivel puede verse distinto según el GIF, así que compruébalo tú en la imagen.
- El resultado es siempre un GIF. Para un GIF largo hecho a partir de un vídeo, un vídeo MP4 o WebM de la misma calidad, o un WebP animado, pesa mucho menos. web.dev recomienda sustituir los GIF grandes de las páginas web por vídeo. Si el sitio donde subes acepta vídeo, esa es la mejor opción.
- Los datos añadidos, como comentarios y XMP, y el guardado entrelazado no se conservan en el resultado. El número de repeticiones (sin fin, una vez o n veces) se deja como en el original.
- La reproducción de la imagen es el navegador reproduciendo dos GIF por separado, así que en un GIF muy largo el original y el resultado pueden desfasarse un poco. Para comparar con exactitud el mismo instante, pausa y avanza fotograma a fotograma.
Referencia: el 2026-10-21 se comprobaron las frases correspondientes de los documentos de abajo. Las cifras de tamaño son valores medidos al reducir los GIF de ejemplo con el motor de esta herramienta.
Fuentes
- 01W3C — Graphics Interchange Format Version 89aPosición y tamaño del descriptor de imagen, tamaño de la tabla de colores 2N+1, métodos de eliminación 0 a 3, tiempo de retardo (1/100 s), índice transparente, códigos LZW de 12 bits como máximo
- 02Manual de gifsicle — --lossy, --optimizeLa opción que reduce el tamaño cambiando colores de píxeles con LZW con pérdida, y los niveles de optimización de fotogramas
- 03Welch, T. A. (1984). A Technique for High-Performance Data Compression. Computer, 17(6), 8–19Compresión LZW
- 04Heckbert, P. (1982). Color image quantization for frame buffer display. SIGGRAPH '82, 297–307Reducción de colores con median cut
- 05GitHub Docs — Attaching filesImágenes y GIF de hasta 10MB
- 06web.dev — Replace animated GIFs with video for faster page loadsSustituir los GIF grandes por vídeo reduce mucho el tamaño
- 07WebKit — ScalableImageDecoder.cppUn comentario que dice que los fotogramas con un retardo de 0,01 s (10 ms) o menos se muestran con 0,1 s, como en Firefox
- 08NIST — Prefixes for binary multipleskilo = 103, kibi = 210
Preguntas frecuentes
¿Se sube el GIF a un servidor?
No. El GIF se lee y se reescribe solo dentro de este navegador. La compresión se hace en un hilo de trabajo de la página y el archivo no se envía a ningún servidor. Al cerrar la pestaña el resultado desaparece, así que guarda los que necesites.
¿Cómo reduce el tamaño si es sin pérdida?
Solo se guarda el rectángulo que rodea a los píxeles que cambian respecto al fotograma anterior, los píxeles sin cambios de su interior se vacían con el índice transparente y un fotograma idéntico al anterior solo le suma su tiempo. Los colores se quedan como estaban. La grabación de pantalla de ejemplo, que guarda la pantalla entera en cada fotograma, pasó de 400 KB a 87 KB.
¿Qué nivel debo elegir?
Empieza con Medio. Un GIF con muchas zonas de color plano, como una grabación de pantalla, suele quedar bastante pequeño solo con Sin pérdida o Ligero, y un GIF hecho a partir de un vídeo se reduce mucho con Medio. Desde Fuerte los colores bajan a 128 o menos y pueden verse bandas o rayas, así que compruébalo en la imagen.
¿Cómo consigo que pese menos de 10 MB?
Elige 10 MB como tamaño objetivo. La herramienta construye de verdad desde Sin pérdida hacia arriba y elige el nivel más ligero que queda en 10 MB o menos. Si ni siquiera Fuerte llega, mantiene Fuerte y reduce el ancho hasta encontrar el mayor que cabe. Los tamaños se cuentan con 1 MB = 1.000.000 de bytes.
El resultado pesa lo mismo que el original.
Si el GIF ya estaba bien comprimido, o es un GIF de vídeo en el que el ruido cambia todos los píxeles de todos los fotogramas, Sin pérdida no consigue reducirlo. Entonces la herramienta te entrega el original. Con Ligero o Medio cedes un poco de calidad y se reduce más.
¿Quitar fotogramas hace que el GIF vaya más rápido?
No. Si dejas 1 de cada 2 fotogramas, el tiempo de los eliminados se suma a los que quedan, así que la duración total es la misma. Solo se pierde fluidez en el movimiento. Los fotogramas escritos con 0 o 0,01 s se cuentan como 0,1 s al sumarlos, tal como los muestran Safari (WebKit) y Firefox.
¿Se puede comprimir un GIF con fondo transparente?
Sí. Ni siquiera en los niveles con pérdida se cambian entre sí los píxeles transparentes y los opacos, así que el contorno se conserva. Cuando una zona debe volver a ser transparente, el fotograma anterior se cambia a restaurar al fondo para vaciar esa zona antes de dibujar el siguiente.
¿Cuántos MB y fotogramas admite?
Un GIF de hasta 50 MB, 1.000 fotogramas y ancho × alto × fotogramas de 150 millones de píxeles, con cada lado de hasta 8.000px. Este margen lo fija la herramienta para que el navegador no se bloquee, y un GIF grande puede tardar unos segundos en cada nivel.