Compresor de imágenes gratuito en línea

Cómo funciona

1. Seleccione o suelte una o varias imágenes arriba.
2. Ajuste el control de calidad (menor = archivo más pequeño, más compresión).
3. Las imágenes se comprimen en su navegador · no se sube nada.
4. Descargue las imágenes comprimidas una a una o todas a la vez.

¿Por qué comprimir imágenes?

Las imágenes pesadas ralentizan los sitios web, aumentan la tasa de rebote y perjudican su posicionamiento en Google. Comprimir imágenes reduce el tamaño del archivo entre un 50% y un 80% con una pérdida de calidad visual mínima. Es esencial para desarrolladores web, blogueros, tiendas online y cualquiera que publique contenido en internet. Las imágenes más ligeras también ahorran ancho de banda en dispositivos móviles y mejoran las puntuaciones de Core Web Vitals.

Qué significa realmente «compresión de imagen»

La compresión de imagen abarca dos operaciones fundamentalmente diferentes que comparten nombre. La compresión con pérdida, usada por JPEG y WebP en modo con pérdida, descarta datos de imagen que el ojo humano difícilmente notará (graduaciones sutiles en las sombras, ruido de alta frecuencia, submuestreo de croma respecto a la luminancia para aprovechar la percepción humana). La salida es más pequeña que la entrada pero no puede reconstruirse bit a bit. La compresión sin pérdida, usada por PNG, GIF, TIFF-LZW y WebP sin pérdida, codifica los datos de píxel exactos de forma más compacta con algoritmos como DEFLATE (LZ77 + Huffman). La salida es más pequeña, y la descompresión reproduce el original byte por byte. Cuál es la adecuada depende de la imagen: las fotografías toleran muy bien la pérdida porque su contenido está lleno de textura que el ojo no rastrea a nivel de píxel; los logotipos, capturas y gráficos con transiciones de color nítidas exigen el sin pérdida porque cada píxel es intencional.

Los ajustes de calidad en un compresor JPEG (el deslizador de esta herramienta, de 10 a 100 %) controlan las tablas de cuantización aplicadas tras el paso DCT. A calidad 100 las tablas apenas redondean coeficientes de frecuencia; a calidad 50 redondean de forma agresiva. Más calidad significa archivos mayores con detalle más fino; menos calidad significa archivos más pequeños con artefactos en bloques visibles en zonas planas. El valor por defecto del 60 % se sitúa en el punto dulce para uso web: normalmente una reducción del tamaño del 50 al 80 % sin cambios perceptibles en una pantalla típica. Para impresión o pantallas grandes, súbelo a 80-90 %. Para miniaturas o versiones aptas para correo, 30-50 % funciona bien.

Para PNG, el deslizador de «calidad» no se aplica en el sentido habitual porque PNG es siempre sin pérdida. Lo que esta herramienta hace realmente con entradas PNG es ejecutar una pasada DEFLATE más enérgica que la que la mayoría del software de edición (Photoshop, Affinity, Sketch) usa por defecto; eso suele recortar un 5 a 25 % del tamaño del archivo sin cambiar ningún píxel. El menú Formato también permite convertir PNG a JPEG o WebP, lo que intercambia el sin pérdida por un archivo mucho más pequeño pero pierde la transparencia para la salida JPEG y (para contenido fotográfico) la garantía de sin pérdida para WebP. La opción Ancho máximo redimensiona las imágenes durante la compresión: una foto de 4000 píxeles de ancho reducida a 1920 píxeles ahorra un 75 % del número bruto de píxeles antes incluso de que se ejecute ninguna compresión, y eso se suma a la reducción de calidad.

Cómo funciona esta herramienta por dentro

El motor de compresión es browser-image-compression de Donald Wong (GitHub: Donaldcwl/browser-image-compression, licencia MIT). Es una biblioteca de JavaScript puro, unos 95 KB minificados, que envuelve tres primitivas del navegador: la API File para leer bytes, la API Canvas (o OffscreenCanvas cuando está disponible) para decodificar, redimensionar y recodificar imágenes JPEG/WebP, y UZIP (una pequeña biblioteca DEFLATE) para procesar PNG sin pasar por Canvas. Cuando dejas caer una imagen, el navegador entrega los bytes a la biblioteca; la biblioteca elige el camino según el formato de entrada y la salida solicitada.

Para entradas JPEG y WebP, el camino es: decodificar a un canvas, redimensionar opcionalmente al Ancho máximo configurado y llamar a canvas.toBlob(mimeType, calidad/100). El codificador JPEG o WebP integrado del navegador hace la cuantización y la codificación de Huffman reales. La calidad es el valor de tu deslizador dividido entre 100, pasado como segundo argumento. Para entradas PNG que se mantienen como PNG, la biblioteca evita Canvas por completo (un viaje de ida y vuelta por Canvas rasterizaría innecesariamente los datos sin pérdida) y, en su lugar, ejecuta UZIP directamente sobre los bloques IDAT del archivo PNG, con el máximo esfuerzo de compresión. Por eso la compresión PNG a PNG aquí es realmente sin pérdida: los datos de píxel nunca se decodifican ni se recodifican, solo se aprieta el envoltorio DEFLATE.

Cuando OffscreenCanvas está soportado (Chrome, Edge, Safari, Firefox modernos), el trabajo pesado de decodificar-redimensionar-codificar se ejecuta dentro de un Web Worker, manteniendo el hilo principal de la interfaz receptivo. Puedes soltar un lote de 20 fotos y seguir desplazándote por la página mientras cada una se procesa. En navegadores más antiguos, la biblioteca recurre al hilo principal, que aún funciona pero bloquea la página durante trabajos grandes. Toda la canalización se ejecuta dentro de tu pestaña. La biblioteca se carga una vez desde un CDN (unos 95 KB minificados) en la primera visita, y se cachea después. Ningún contenido de archivo abandona jamás el navegador. Abre la pestaña Red en DevTools mientras comprimes un lote y verás la descarga única de la biblioteca pero nada más.

Una breve historia de los formatos de compresión de imagen

• DCT, 1972-1974. Nasir Ahmed propuso la transformada discreta del coseno como método de compresión de imagen en 1972; el algoritmo formal se publicó con T. Natarajan y K. R. Rao en 1974. Esta única transformación matemática está bajo cada archivo JPEG, MPEG y H.26x del mundo hoy.
• JPEG, 1992. El Joint Photographic Experts Group (formado en 1986) estandarizó JPEG como ITU-T T.81 / ISO/IEC 10918-1 en 1992. Bloques DCT 8x8, espacio de color YCbCr con submuestreo de croma opcional, tablas de cuantización ajustadas a la visión humana. El formato que hizo posible la web rica en fotos.
• PNG, 1996. Creado en el IETF como RFC 2083 para reemplazar a GIF tras las reclamaciones de patente de Unisys sobre LZW que amenazaron la web abierta. Compresión DEFLATE (LZ77 + Huffman), siempre sin pérdida, transparencia alfa completa, sin gravamen de patentes. La 3.ª edición de la especificación (W3C, 2023) añadió oficialmente HDR, animación APNG y metadatos EXIF.
• WebP, 2010. Google lanzó WebP como formato de imagen fija basado en la codificación intracuadro del códec de vídeo VP8. WebP con pérdida es un 25-34 % más pequeño que JPEG con calidad visual comparable; WebP sin pérdida es alrededor de un 26 % más pequeño que PNG. La adopción tardó una década; en 2026 más del 96 % de los navegadores del mundo lo admiten.
• AVIF, 2019. La Alliance for Open Media lanzó AVIF como la variante de imagen fija del códec de vídeo AV1. Alrededor de un 50 % más pequeño que JPEG a calidad comparable. El soporte de navegadores supera ya el 95 %, pero el soporte de codificadores en herramientas cotidianas de autoría (Photoshop, Word, Slack) va por detrás. Squoosh e ImageMagick pueden producir AVIF hoy; la mayoría de cámaras y teléfonos no.
• HEIC, 2017. Apple adoptó HEIC, basado en HEIF/H.265, como formato de foto por defecto del iPhone. Alrededor de la mitad del tamaño del JPEG equivalente. Gravado con regalías, por lo que rara vez se sirve en la web abierta. La mayoría de subidores en línea (incluida esta herramienta) solo aceptan HEIC tras una conversión a JPEG en escritorio; esa conversión es el flujo diario para enviar fotos del móvil a un destinatario no-Apple.

Formatos compatibles

• JPEG · Ideal para fotos e imágenes complejas. Compresión con pérdida y calidad ajustable.
• PNG · Ideal para gráficos, logotipos e imágenes con transparencia.
• WebP · El formato moderno de Google, con archivos más pequeños que JPEG/PNG a calidad comparable.

Flujos de compresión del mundo real

• Imágenes de blog y sitio web. Un JPEG de 2 MB directo del teléfono frente a un JPEG comprimido de 250 KB: idénticos al ojo humano en una pantalla típica, pero el archivo más pequeño carga aproximadamente 8 veces más rápido. Las puntuaciones de Core Web Vitals (LCP) mejoran directamente. La mayoría de páginas con varias fotos ven las mayores mejoras de Lighthouse a partir de la compresión de imágenes, no de la optimización de JavaScript o CSS.
• Subidas a redes sociales. Instagram, Twitter, Facebook y LinkedIn recomprimen todas las imágenes al subirlas con sus propios algoritmos. Comprimir antes te da control sobre lo que se sacrifica; subir fotos en bruto deja esas decisiones a la plataforma, a menudo con degradación visible.
• Adjuntos de correo electrónico. La mayoría de proveedores limitan los adjuntos a 25 MB por mensaje (Gmail, Outlook, Apple Mail). Comprimir una carpeta de fotos de unos 50 MB a unos 10 MB permite enviar todo en un solo correo en lugar de repartirlo en varios envíos o pasar a un enlace de almacenamiento en la nube.
• Fotos de productos de comercio electrónico. Los catálogos de productos con cientos o miles de fotos generan grandes facturas de ancho de banda en CDN y cargas de página lentas. Comprimir toda la biblioteca recorta ambas cosas. Los vendedores de Shopify, Etsy y Amazon comprimen rutinariamente antes de subir para bajar costes de hospedaje y mejorar posicionamiento.
• Portafolios con muchas capturas. Los portafolios de diseño de interfaz son ricos en PNG porque las capturas tienen transiciones de color nítidas donde los artefactos JPEG se notarían. PNG a PNG con DEFLATE más apretado suele ahorrar entre un 10 y un 20 % sin cambios de píxel, útil para sitios de portafolio de diseñadores que necesitan ser rápidos sin sacrificar calidad de renderizado.
• Reducción de archivos. Una foto de 12 megapíxeles de un teléfono es excesiva para un álbum familiar que solo se verá en pantallas. Redimensionar a 4 megapíxeles al 80 % de calidad: el resultado luce idéntico en cada dispositivo que vaya a verlo y el archivo cae a una quinta parte del tamaño original. Los originales se quedan a salvo en el disco fuente; las versiones comprimidas van al espacio de compartido o copia de seguridad.

Errores comunes y su significado

• Recomprimir un JPEG varias veces lo degrada. Cada vez que se guarda un JPEG se vuelve a ejecutar el paso de cuantización DCT, perdiendo detalle que ya no podrás recuperar. Las pérdidas son sutiles en el primer paso y obvias en el tercero o cuarto. Comprime siempre desde la fuente de mayor calidad que tengas (el archivo original de la cámara, la exportación de tu herramienta de diseño), no desde un JPEG previamente comprimido que guardaste la semana pasada. Si necesitas hacer ajustes, mantén una copia maestra en PNG o TIFF.
• PNG a JPEG pierde la transparencia. JPEG simplemente no tiene canal alfa en la especificación. Cualquier píxel transparente se vuelve blanco sólido (o lo que el codificador sustituya) al convertir PNG a JPEG. Para logotipos, iconos, capturas con fondos transparentes o cualquier gráfico con canal alfa, quédate en PNG o pasa a WebP, que conservan la transparencia.
• JPEG a PNG hace que el archivo crezca. La compresión DEFLATE de PNG es buena con degradados suaves y zonas planas grandes, y terrible con los patrones de ruido de alta frecuencia que deja la compresión JPEG. Convertir un JPEG a PNG suele duplicar o triplicar el tamaño del archivo sin mejora de calidad. Si necesitas sin pérdida a partir de un JPEG ya es tarde: la información original se perdió. La conversión tiene sentido solo si necesitas específicamente la transparencia de PNG o una herramienta que no acepta JPEG.
• Los metadatos EXIF se eliminan por defecto. La biblioteca browser-image-compression descarta por defecto los metadatos EXIF (información de cámara, coordenadas GPS, fecha de captura, perfil de color ICC) durante la recompresión. Para uso web suele ser una virtud (la filtración de coordenadas GPS es un problema de privacidad real). Para fotógrafos que archivan con metadatos intactos, esta herramienta no es la adecuada; usa un compresor de escritorio consciente de EXIF como ImageOptim o jpegtran con la opción explícita de «preservar metadatos».
• Los perfiles de color pueden no sobrevivir. Un perfil de color ICC incrustado (sRGB, Adobe RGB, ProPhoto) le dice a las pantallas cómo interpretar los valores de píxel. La recodificación basada en Canvas puede descartar el perfil incrustado y etiquetar la salida como sRGB. Para uso normal en pantalla está bien porque casi todo es sRGB de todos modos. Para trabajos de preparación de impresión, preparación de fotos con gestión de color o entregables de gama amplia, usa una herramienta consciente del color (Photoshop Exportar como, Affinity, RawTherapee) que preserve explícitamente los datos de perfil.
• Imágenes muy grandes pueden bloquear una pestaña móvil. Decodificar una imagen a Canvas necesita RAM proporcional a sus dimensiones: una foto de 24 megapíxeles (6000x4000 píxeles) necesita unos 96 MB solo para el búfer de píxeles RGBA, más la memoria de trabajo del codificador. Los dispositivos móviles con 4 GB de RAM pueden ver la pestaña cerrada por el sistema operativo antes de que termine la codificación. Redimensiona la entrada o usa un navegador de escritorio para fotos muy grandes.

Privacidad: las imágenes se quedan en tu dispositivo

Cada compresor de imágenes en la nube (TinyPNG, Compressor.io, Optimizilla, las herramientas de imagen de Smallpdf, el endpoint de compresión de Pixlr, las decenas de servicios «comprimir imagen online») sube tu archivo a los servidores del operador, ejecuta su algoritmo de compresión y devuelve la imagen más pequeña como descarga. Las implicaciones de privacidad no son triviales porque las fotos rutinariamente contienen contenido identificable: rostros, direcciones visibles al fondo, capturas de interfaces internas o documentos confidenciales, fotos de menores, fotos tomadas en espacios privados. La mayoría de operadores publican políticas de privacidad comprometiéndose a borrar las subidas en una o dos horas y a cifrar en tránsito, y los más grandes (TinyPNG, Smallpdf) ostentan certificación ISO/IEC 27001. Tienen fuertes incentivos comerciales para honrarlas. Pero «borrado en una hora» no es «nunca visto». Durante esa hora el contenido de la imagen está en la infraestructura del operador, accesible a cualquier proceso o persona con permisos adecuados, y visible en registros y copias según la política de retención aplicable.

Este compresor nunca sube nada. La biblioteca browser-image-compression se ejecuta por completo en tu pestaña; los bytes de imagen los lee la API File, se procesan en JavaScript (o en un Web Worker si OffscreenCanvas está disponible), y la salida comprimida se devuelve a la misma pestaña como un Blob descargable. Puedes verificar la ausencia de subida abriendo las herramientas de desarrollo del navegador en la pestaña Red antes de comprimir un lote: no se dispara ninguna petición con el contenido de tu imagen. El único tráfico de red es la descarga única de la biblioteca (~95 KB) desde el CDN en la primera visita, tras lo cual la biblioteca queda en caché. Pon el navegador en modo avión después de cargar la página y el compresor sigue funcionando sobre archivos locales. Para fotos con cualquier cosa sensible (rostros, ubicaciones, capturas internas), claramente vale la pena el compromiso del lado navegador.

Cuándo otra herramienta es la elección correcta

• Procesar por lotes más de 500 imágenes en una canalización con script. Usa sharp en Node.js (la biblioteca de imagen canónica del servidor), ImageMagick o GraphicsMagick en línea de comandos, o Pillow en Python. Estas herramientas manejan miles de archivos sin límites de memoria del navegador y corren desde trabajos de CI, hooks de despliegue o tareas cron.
• Garantías estrictas de sin pérdida con igualdad de bits verificable. Para PNG a PNG, esta herramienta es genuinamente sin pérdida porque UZIP no toca los datos de píxel. Para flujos que exigen verificación criptográfica (imagen médica, evidencia legal), usa una herramienta de escritorio como ImageMagick con `-define png:compression-level=9` explícito y verificación SHA-256 de los datos de píxel decodificados.
• Preservación de perfiles de color para impresión. Adobe Photoshop, Affinity Photo o RawTherapee para trabajos de preparación de impresión con preservación de perfiles ICC, prueba en pantalla y salida CMYK. La compresión basada en navegador no puede garantizar flujos con gestión de color porque Canvas opera en sRGB y puede descartar los datos del perfil incrustado.
• Salida AVIF para compresión de próxima generación. browser-image-compression no produce AVIF a fecha de 2026. Para codificación AVIF en el navegador, usa Squoosh (también de Google, también en el cliente); para AVIF en línea de comandos, usa avifenc de libavif. AVIF produce archivos más o menos un 50 % más pequeños que JPEG a calidad comparable, pero el codificador es costoso (10 veces más lento que el de JPEG).

Preguntas frecuentes

¿La compresión reduce la calidad de la imagen?

Con la calidad predeterminada del 60%, la mayoría de las imágenes se ven casi idénticas al original pero pesan entre un 50% y un 80% menos. Ajuste el control para encontrar el equilibrio adecuado a sus necesidades.

¿Hay un límite de tamaño de archivo?

Cada imagen puede pesar hasta 50 MB. Como el procesamiento ocurre en su navegador, los archivos muy grandes pueden tardar un momento según su dispositivo.

¿Mis imágenes se suben a un servidor?

No. Toda la compresión se realiza localmente en su navegador. Sus imágenes no salen de su dispositivo, por lo que la herramienta es totalmente privada y segura.

¿Qué ajuste de calidad debo usar?

Para uso web, entre 60% y 70% es ideal. Para impresión o porfolios, pruebe con 80-90%. Para compresión máxima (miniaturas, correo electrónico), 30-50% funciona bien.

Más preguntas frecuentes

¿Por qué mi salida PNG es solo un poco más pequeña que el original?

PNG es sin pérdida. El ahorro viene íntegramente de encontrar una compresión DEFLATE más apretada sobre los mismos datos de píxel, lo que normalmente recorta entre 5 y 25 % frente a lo que una herramienta de edición (Photoshop, Sketch, Figma) escribió por defecto. Si tu PNG ya estaba bien optimizado, queda poco margen. Para conseguir reducción adicional significativa, convierte a WebP (que conserva transparencia y suele ser un 25 % más pequeño que PNG) o acepta algo de pérdida convirtiendo a JPEG (que puede ser mucho más pequeño pero descarta la transparencia).

¿Funciona esta herramienta sin conexión?

Tras la primera visita, sí. La biblioteca browser-image-compression (unos 95 KB minificados) la guarda el navegador en caché en la primera carga. Las visitas siguientes al compresor funcionan totalmente sin conexión, siempre que la caché del navegador no se haya borrado. Puedes comprobarlo activando el modo avión tras abrir la página una vez y comprimiendo una imagen local.

¿Se conservarán mis datos EXIF (cámara, GPS, fecha de captura)?

No, los metadatos EXIF se retiran durante la compresión por defecto. Para compartir en web suele ser deseable (las coordenadas GPS y los números de serie de cámara no deberían filtrarse), pero para fotógrafos que archivan con metadatos intactos esta herramienta no es la indicada. Usa un compresor de escritorio consciente de EXIF como ImageOptim (macOS) o jpegtran con la opción `-copy all` para preservar metadatos.

¿Cuál es la diferencia entre el redimensionado Max Width y la reducción de calidad?

Redimensionar cambia las dimensiones en píxeles de la imagen: una foto de 4000x3000 redimensionada a 1920x1440 tiene un 75 % menos de píxeles que codificar, lo que recorta el tamaño antes incluso de que se ejecute ninguna compresión. La reducción de calidad (el deslizador) controla con cuánta agresividad el codificador JPEG o WebP redondea sus coeficientes DCT, lo que hace los datos codificados más pequeños por píxel. Ambos se suman: redimensiona primero para bajar el conteo global de píxeles, después reduce la calidad de lo que quede. Para un flujo «hazme esto apto para web» típico, Max Width 1920 y calidad 70, y la salida es aproximadamente el 10-15 % del tamaño original.

¿Puedo comprimir imágenes HEIC de mi iPhone?

El soporte de los navegadores para decodificar HEIC es limitado (Safari en dispositivos Apple lo hace; Chrome y Firefox no). En navegadores no-Apple esta herramienta rechazará los archivos HEIC. El flujo para fotos de iPhone es o cambiar el ajuste del iPhone (Cámara → Formatos → Más compatible) para guardar JPEG directamente, o convertir HEIC a JPEG una vez en un Mac o con una herramienta dedicada, y luego pasar esos JPEG por este compresor. La hoja «Compartir vía» de iCloud suele convertir automáticamente a JPEG al compartir con destinatarios no-Apple.

¿Existe un equivalente de escritorio o de línea de comandos?

Varios. Para automatización por lotes, sharp en Node.js es la biblioteca canónica del lado servidor y produce salida casi idéntica. ImageMagick (magick input.jpg -quality 70 output.jpg) y GraphicsMagick manejan archivos enormes y corren desde cualquier shell. jpegoptim y optipng son recodificadores especializados de JPEG y PNG que a menudo arañan unos puntos porcentuales adicionales frente a herramientas genéricas. Para trabajo interactivo puntual como esta herramienta pero con más controles, Squoosh (Google Chrome Labs, también enteramente en el cliente) admite una gama más amplia de formatos incluyendo AVIF.

Herramientas relacionadas