Comprimir Imágenes & Reducir Fotos

Comprimir Imágenes & Reducir Fotos

Comprime imágenes online sin pérdida de calidad. Reduce el tamaño de JPG, PNG y WebP en tu navegador sin subir datos al servidor, con objetivo en KB y exportación en ZIP.

Preajustes:
Modo de Compresión

Arrastra fotos aquí o haz clic para seleccionar

Compatible con JPG, PNG, WebP, AVIF, GIF, SVG y BMP. Cero transferencias al servidor.

240 KB
Dimensiones Máximas
Ancho:
Alto:
Canal de Procesamiento en el ClienteOffscreenCanvas / O(N)
DECRESDCTBINZIP
0.980
Fidelidad Visual SSIMPerceptualmente Sin Pérdidas
Reducción de Tamaño:-0.0%
0 B0 B
Aumento de Lupa:
Separador de Comparación: 50%

No hay imágenes en cola. Arrastra fotos arriba para optimizar por lotes.

Tamaño Original0 B
Tamaño Comprimido0 B
Ahorro de Datos0 B
Ratio de Compresión0.0%
Referencia técnica y guía de arquitectura

Comprimir Imágenes & Reducir Fotos — Guía de referencia

Comprime imágenes online sin pérdida de calidad. Reduce el tamaño de archivos JPG, PNG y WebP en el navegador sin subir datos al servidor, con ajuste exacto de KB y exportación por lotes en ZIP.

Comprimir Imágenes & Reducir Fotos — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos
Comprimir Imágenes & Reducir Fotos — Guía de referencia — Arquitectura en memoria del lado del cliente y flujo de datos

Parámetros clave y controles

Archivos de origenFileList | Flujo Drag-and-Drop

Búferes de bytes de imagen sin procesar decodificados localmente mediante createImageBitmap y FileReader en la memoria aislada del hilo del navegador sin transmisión por sockets de red.

Por defecto: Selección única o múltiple de archivos
Modo de compresión"quality" | "targetSize"

Estrategia algorítmica de ejecución que alterna entre cuantización escalar manual y un algoritmo de búsqueda binaria O(log k) orientado a límites estrictos de bytes.

Por defecto: quality
Formato de salida"image/webp" | "image/jpeg" | "image/png"

Contenedor MIME de destino que determina las tablas de cuantización DCT, la predicción de bloques intra-frame VP8 o las rutinas de filtrado 2D DEFLATE según RFC 1951.

Por defecto: image/webp
Factor de calidadRango decimal [0.01, 1.00]

Escala de cuantización con pérdida transmitida a HTMLCanvasElement.toBlob(). Factores inferiores a 0.70 presentan riesgo de artefactos ringing DCT de alta frecuencia, mientras que 0.80 mantiene un SSIM > 0.95.

Por defecto: 0.80
Límite de tamaño objetivoEntero (Kilobytes, KB)

Umbral máximo de peso de archivo (p. ej., 200 KB para visados Schengen o pasaportes de la UE, 240 KB para el formulario DS-160 de EE. UU.) regulado mediante un bucle de convergencia para búsqueda de raíces inversas.

Por defecto: 200
Dimensiones máximasCuadro delimitador de píxeles (Ancho x Alto)

Resolución espacial máxima regulada mediante remuestreo bicúbico escalonado para restringir el total de operaciones por píxel a O(W × H) y evitar fallos por falta de memoria (OOM) en el canvas de WebKit.

Por defecto: 1920 x 1080 px
Cuantización de colorProfundidad de paleta (256 | 128 | 64 colores | Completa)

Matriz de reducción de color para recursos PNG que ejecuta particionamiento espacial octree y tramado Floyd-Steinberg para preservar la transparencia alfa dentro de límites indexados de 8 bits.

Por defecto: Color completo (24 bits)
Sanitización EXIF"strip" | "safe" | "retain"

Barrera de privacidad de metadatos que purga segmentos TIFF/Exif (coordenadas GPS, identificadores de serie de la cámara y marcas de tiempo) durante la reserialización ráster en canvas.

Por defecto: strip

Consejos profesionales y mejores prácticas

Comparativa de eficiencia de compresión: WebP frente a JPEG

Convertir recursos fotográficos de JPEG estándar a WebP reduce el peso del archivo entre un 25 % y un 35 % con un índice de similitud estructural idéntico (SSIM > 0.95). WebP aprovecha la predicción de macrobloques intra-frame de VP8 y la codificación aritmética discreta, suprimiendo los artefactos de ringing DCT en bordes de alto contraste.

Mitigación de límites de memoria de canvas en WebKit móvil

iOS Safari impone un límite estricto de memoria en canvas (habitualmente entre 256 MB y 384 MB de asignación acumulada en GPU). Al procesar fotografías de alta resolución (>12 MP), ejecute un submuestreo escalonado mediante OffscreenCanvas o createImageBitmap, y asigne explícitamente canvas.width = canvas.height = 0 tras la compresión para forzar la recolección de basura inmediata del contexto de hardware.

Convergencia por búsqueda binaria para requisitos estrictos de visados y pasaportes

Las plataformas consulares y gubernamentales oficiales imponen límites estrictos de tamaño de archivo (p. ej., 240 KB para el formulario estadounidense DS-160 o 200 KB para visados Schengen de la UE y pasaportes). Utilice el modo de tamaño objetivo, que ejecuta una búsqueda binaria automatizada de 7 pasos sobre los parámetros de cuantización de JPEG/WebP, convergiendo a la máxima calidad perceptual en menos de 300 ms sin ensayos manuales.

Cuantización de paleta por octree para elementos de interfaz con canal alfa

Para iconos de interfaz, logotipos y capturas de pantalla con áreas de color plano y transparencia alfa, la conversión a JPEG destruye la transparencia, mientras que WebP con pérdida puede generar halos en los bordes. Aplicar una cuantización de paleta octree de 8 bits con tramado Floyd-Steinberg a archivos PNG logra una reducción del 60 % al 75 % del tamaño del archivo preservando una definición de bordes pixel-perfect.

Problemas comunes y soluciones

⚠️El archivo comprimido resultante es más grande que el original

Volver a codificar un archivo JPEG o WebP previamente comprimido con un ajuste de calidad alto (≥85 %) obliga al codificador por transformada a tratar el ruido de cuantización y los artefactos de bloque existentes como información genuina de alta frecuencia, inflando la tabla de entropía. Ajuste la calidad al 75 % o aplique una reducción dimensional del 10 % para recuantizar el dominio de la frecuencia de manera eficiente.

⚠️El fondo transparente se vuelve negro o blanco sólido tras la compresión

El contenedor estándar JPEG (ISO/IEC 10918-1 / JFIF) no admite canal de transparencia alfa y fusiona los píxeles translúcidos contra una base mate opaca. Cambie el formato de salida de destino a WebP (que admite compresión con pérdida y canales alfa de 8 bits) o a PNG cuantizado de 8 bits.

⚠️El optimizador de tamaño objetivo no alcanza un límite extremadamente bajo en kilobytes

Al solicitar un límite de tamaño muy agresivo (como <50 KB en una imagen 4K), la cuantización alcanza el suelo de calidad mínima (1 %), donde las tablas de encabezado base DCT y los códigos run-length mínimos no pueden comprimir más. Active la reducción de Dimensiones máximas para reducir la superficie de píxeles proporcionalmente, ya que el peso en bytes escala cuadráticamente con las dimensiones lineales.

⚠️El navegador móvil se congela o reinicia la pestaña durante el procesamiento por lotes

Decodificar varias fotografías de cámara simultáneamente supera los límites de VRAM en dispositivos móviles, lo que provoca el cierre forzado de la pestaña por el navegador. Limite la concurrencia de procesamiento por lotes a 1 (ejecución secuencial serializada) en los ajustes, permitiendo liberar y recolectar la memoria de cada búfer de imagen antes de inicializar el siguiente contexto de decodificación.

Preguntas frecuentes (FAQ)

¿Cómo calcula la compresión por tamaño objetivo los límites exactos en KB?▼

La compresión por tamaño objetivo ejecuta una búsqueda binaria O(log k) sobre el espacio de parámetros de cuantización de la transformada de coseno discreta (DCT) [1, 100]. En cada iteración, el codificador de canvas evalúa canvas.toBlob() frente al límite de bytes; si el payload excede el objetivo, se bisecciona el límite superior, convergiendo a la mayor calidad visual posible en 7 iteraciones y en menos de 300 ms.

¿Cuál es el balance óptimo entre calidad de imagen y tamaño de archivo para el rendimiento web?▼

El estándar recomendado para la web se sitúa entre el 75 % y el 82 % de calidad en formato WebP, manteniendo un índice de similitud estructural (SSIM) superior a 0.96 y limitando las imágenes hero por debajo de 150 KB y las miniaturas de contenido por debajo de 70 KB. Esto cumple con las métricas de Google Core Web Vitals para Largest Contentful Paint (LCP < 2,5 s) sin introducir artefactos de compresión perceptibles de alta frecuencia.

WebP frente a JPEG y PNG: ¿qué formato genera el tamaño de archivo más reducido?▼

WebP ofrece archivos entre un 25 % y un 35 % más pequeños que JPEG estándar con una fidelidad visual equivalente medida por SSIM gracias a la predicción de macrobloques intra-frame de VP8, y reduce el tamaño de PNG de 24 bits en más de un 70 % mediante transparencia alfa con pérdida. PNG sigue siendo indispensable únicamente para recursos gráficos vectoriales rasterizados sin pérdida o paletas indexadas de 8 bits donde la nitidez en bordes tipográficos no debe sufrir ruido de cuantización DCT.

¿Por qué recomprimir una imagen ya comprimida puede aumentar el tamaño del archivo?▼

La codificación por transformada con pérdida no es idempotente: recomprimir una imagen con una calidad elevada (≥85 %) desalinea los límites de los bloques DCT de 8x8, lo que obliga al codificador entrópico a registrar los artefactos de compresión previos como datos legítimos de alta frecuencia. Esto infla las tablas de codificación Huffman o aritmética, provocando un aumento del 10 % al 25 % en el peso final a menos que se recuantice de forma agresiva.

¿Cómo protege la privacidad de imágenes confidenciales la ejecución directa en el navegador?▼

Todas las operaciones de decodificación, remuestreo y recodificación se ejecutan íntegramente en la memoria local mediante la API Canvas de HTML5, createImageBitmap y Web Workers, sin realizar ninguna solicitud HTTP saliente hacia servidores externos. La integridad criptográfica puede verificarse mediante la Web Crypto API (crypto.subtle.digest) en el sandbox del origen local, garantizando el pleno cumplimiento de normativas de privacidad como el RGPD (GDPR), HIPAA y las especificaciones de seguridad de RFC 6454.

¿Por qué los fondos transparentes se vuelven negros o blancos al convertir a JPG?▼

La especificación JPEG (JFIF / ISO/IEC 10918-1) carece de soporte para canal alfa y únicamente codifica planos de luminancia y crominancia YCbCr. Al exportar búferes de píxeles RGBA de canvas a image/jpeg, el navegador combina automáticamente los píxeles transparentes sobre un fondo mate opaco (habitualmente negro 0x000000 o blanco 0xFFFFFF); para conservar la transparencia es obligatorio seleccionar WebP o PNG.

Herramientas y utilidades relacionadas

Todas las herramientas →