Comprimir Imagen — Compresor JPG, PNG, WebP Online Gratis

Q: ¿Cómo enruta el compresor distintos formatos — JPG, PNG, WebP, BMP?

La herramienta usa la librería browser-image-compression de amplio uso (Donaldcwl, licencia MIT) que detecta el tipo MIME y enruta al pipeline apropiado: los JPG pasan por Canvas toBlob('image/jpeg', quality) que recodifica vía la cuantización DCT + Huffman de JPEG según ITU-T T.81 Anexo K (con pérdida); los WebP pasan por Canvas toBlob('image/webp', quality) que usa VP8 (RFC 6386 Bankoski et al., noviembre 2011) para el modo con pérdida o LZ77 + codificación Huffman/prefix para sin pérdida; los PNG omiten Canvas y usan UZIP (una implementación JavaScript de DEFLATE según RFC 1951 Deutsch, mayo 1996) para recompresión sin pérdida con potencialmente mejor selección de filtro.

Q: ¿La compresión PNG funciona igual que la compresión JPG y WebP?

No, fundamentalmente distinta. PNG (W3C 2ª Edición, 10 noviembre 2003 / ISO/IEC 15948:2004) es sin pérdida por diseño — cada píxel se preserva exactamente a través de la recodificación DEFLATE. La ganancia de compresión viene de optimizar la selección de filtro (5 tipos de filtro por línea de exploración) y el nivel de compresión zlib, NO de descartar datos visuales. Ahorros esperados: 5–30% para PNGs típicos (mucho menos que el 40–70% de JPG). Para PNG cuantizado a paleta con pérdida (reducción de tamaño significativa hasta 70%) necesitarías una herramienta usando libimagequant/pngquant — esta herramienta NO hace cuantización de paleta, solo recodificación DEFLATE sin pérdida.

Q: ¿Qué hace realmente el slider de calidad para cada formato?

JPG: calidad 1–100 mapea a tablas de cuantización JPEG según ITU-T T.81 Anexo K. Mayor = pasos de cuantización más pequeños = más coeficientes DCT preservados = archivo más grande. 85–90 visualmente indistinguible de sin pérdida; 75–85 punto dulce web. WebP: calidad 1–100 controla el cuantizador VP8 para modo con pérdida (Firefox 105+ soporta sin pérdida vía quality=1.0). PNG: el slider de calidad NO tiene efecto — PNG es sin pérdida independientemente. El tamaño de salida depende solo de la selección de filtro y nivel zlib.

Q: ¿Sobrevivirán los metadatos EXIF de mi imagen a la compresión?

Depende del formato y la configuración. JPG: por defecto Canvas toBlob() elimina EXIF (JEITA CP-3451X / CIPA DC-X008-2019, Exif 2.32, revisada 17 mayo 2019); browser-image-compression tiene un flag opt-in 'preserveExif' que retiene los marcadores APP1 — el beneficio de privacidad es el comportamiento por defecto (coordenadas GPS, número de serie de cámara descartados). PNG: el PNG nativo no tiene chunk EXIF ampliamente soportado; los metadatos típicamente se descartan. WebP: admite chunk EXIF según RFC 9649 §2.7.1.5 pero la recodificación Canvas lo elimina.

Q: ¿El compresor corre mis imágenes en la nube?

No. La herramienta procesa todo localmente vía el Canvas 2D Context del HTML Living Standard de WHATWG (para JPG/WebP) o UZIP (para PNG), corriendo en un hilo Web Worker cuando OffscreenCanvas está disponible. Ningún archivo sale de tu dispositivo — verificable en la pestaña Network de DevTools del navegador (no se disparan peticiones de subida). Crítico para trabajo de cliente bajo NDA, fotos personales con datos de ubicación, o cualquier imagen que prefieras no entregar a un servicio remoto.

Compresor de Imágenes — JPG vía DCT, PNG vía DEFLATE, WebP vía VP8

La compresión de imágenes abarca tres algoritmos fundamentalmente distintos según formato. JPG (ITU-T T.81 / ISO/IEC 10918-1, 18 septiembre 1992) usa cuantización DCT + Huffman con pérdida según Anexo K — calidad 1–100 mapea al escalado de tablas de cuantización. PNG (W3C Recommendation 10 noviembre 2003 / ISO/IEC 15948:2004) usa DEFLATE sin pérdida (RFC 1951 Deutsch, mayo 1996, LZ77 + Huffman con ventana deslizante de 32 KB) — la ganancia de compresión viene de la selección de filtro (5 tipos por línea de exploración) y nivel zlib, no del descarte de píxeles. WebP (RFC 9649 Zern, Massimino y Alakuijala, Google LLC, noviembre 2024) admite tanto modo con pérdida (keyframes VP8 según RFC 6386 Bankoski et al., noviembre 2011) como sin pérdida (LZ77 + codificación Huffman/prefix + caché de color). Esta herramienta usa la librería browser-image-compression de amplio uso (Donaldcwl, licencia MIT): basada en Canvas para JPG/WebP/BMP, basada en UZIP DEFLATE para PNG, con descarga a Web Worker vía OffscreenCanvas cuando está disponible.

Relacionado: Comprimir JPG Comprimir PNG Comprimir WebP Redimensionar Imagen Comprimir Imagen Divisor de Cuadrícula

Cómo comprimir una imagen

Arrastra un archivo JPG/PNG/WebP/BMP a la herramienta o haz clic para seleccionar — archivo suelto o lote.
La herramienta detecta el formato y enruta al pipeline apropiado (Canvas+JPG/WebP, UZIP+PNG).
Ajusta la calidad (efectiva para JPG/WebP — PNG es sin pérdida independientemente). 80–85 es el punto dulce web estándar para fotos.
Revisa los tamaños antes/después (típico: JPG reducción 40–70%, WebP 25–35% más pequeño que JPG, PNG ganancia sin pérdida 5–30%), luego descarga.

Casos de uso comunes

Optimizar una librería de imágenes de formato mixto (fotos JPG + logos PNG + variantes WebP) antes de subir a un CMS en lote.
Reducir el tamaño de adjuntos de correo por debajo de límites de 10 MB / 25 MB sin redimensionar — JPG calidad 75 típicamente sirve.
Mejorar Core Web Vitals (LCP) en páginas con muchas imágenes recodificando todas las hero a calidad 80–85.
Aligerar respaldos de fotos antes de subir a la nube (Google Drive, Dropbox, iCloud) — reducción típica de almacenamiento de 40–60% sin pérdida visible de calidad.

Preguntas frecuentes

¿Cómo enruta el compresor distintos formatos — JPG, PNG, WebP, BMP?

Usa la librería browser-image-compression de amplio uso (Donaldcwl, MIT) que detecta el tipo MIME. Los JPG/WebP pasan por Canvas toBlob() según ITU-T T.81 / RFC 9649. Los PNG omiten Canvas y usan UZIP (DEFLATE JavaScript según RFC 1951) para recompresión sin pérdida con selección de filtro optimizada.

¿La compresión PNG funciona igual que la compresión JPG y WebP?

No, fundamentalmente distinta. PNG (W3C 2ª Ed) es sin pérdida por diseño — la recodificación DEFLATE solo optimiza la selección de filtro + nivel zlib. Ahorros esperados: 5–30% (vs el 40–70% de JPG). Para cuantización de paleta PNG con pérdida (hasta 70% ahorro) necesitarías libimagequant/pngquant.

¿Qué hace realmente el slider de calidad para cada formato?

JPG: calidad 1–100 mapea al escalado Q-table según ITU-T T.81 Anexo K. 85–90 visualmente sin pérdida; 75–85 punto dulce web. WebP: calidad controla el cuantizador VP8 (Firefox 105+ admite quality=1.0 sin pérdida). PNG: el slider de calidad NO tiene efecto — PNG es sin pérdida independientemente.

¿Sobrevivirán los metadatos EXIF de mi imagen a la compresión?

JPG: por defecto Canvas elimina EXIF (JEITA CP-3451X / CIPA DC-X008-2019, Exif 2.32, mayo 2019); browser-image-compression tiene flag opt-in preserveExif. PNG: el PNG nativo no tiene chunk EXIF ampliamente soportado. WebP: admite chunk EXIF según RFC 9649 §2.7.1.5 pero la recodificación Canvas lo elimina.

¿El compresor corre mis imágenes en la nube?

No. Procesamiento local vía WHATWG Canvas 2D Context (JPG/WebP) o UZIP (PNG), corriendo en hilo Web Worker cuando OffscreenCanvas disponible. Ningún archivo sale del dispositivo — verificable en pestaña Network de DevTools (no se disparan peticiones de subida).

Cómo el compresor enruta cada formato — y qué hace realmente el slider de calidad

La librería browser-image-compression detecta el tipo MIME y enruta al pipeline apropiado. Para JPG: decodifica a píxeles vía Canvas → toBlob('image/jpeg', quality) → recodifica vía el codificador JPEG integrado del navegador usando las tablas de cuantización ITU-T T.81 Anexo K. El slider de calidad (1–100) escala directamente las Q-tables — mayor calidad = pasos de cuantización más pequeños = más coeficientes DCT preservados = archivo más grande. Para WebP: mismo pipeline pero toBlob('image/webp', quality) → codificación de keyframe VP8 para modo con pérdida (Firefox 105+ también admite sin pérdida vía quality=1.0). Para PNG: omite Canvas (ya que la salida PNG de Canvas no está optimizada) y usa UZIP — una implementación JavaScript pura de DEFLATE por photopea — para recodificar sin pérdida con selección de filtro optimizada y nivel de compresión zlib más alto (típicamente 5–30% más pequeño que el PNG origen, con cero cambios de píxel). Salvedad crítica: la compresión PNG-a-PNG es estrictamente sin pérdida; el slider de calidad NO tiene efecto en la salida PNG. Asimetría de soporte de navegador: la salida JPG funciona en todas partes; la salida WebP requiere polyfill libwebp WebAssembly en Safari (Safari no soporta image/webp vía canvas.toBlob a fecha de 2026 — una limitación de WebKit rastreada en bugs.webkit.org). Metadatos EXIF: por defecto la recodificación basada en Canvas elimina el EXIF APP1 de JPEG (JEITA CP-3451X / CIPA DC-X008-2019, Exif 2.32, mayo 2019) — beneficio de privacidad; browser-image-compression tiene un flag opt-in preserveExif.

Recodificación JPG vía cuantización ITU-T T.81 Anexo K (calidad 1–100 mapea al escalado Q-table)
Recompresión PNG sin pérdida vía UZIP DEFLATE (RFC 1951) con selección de filtro optimizada
Recodificación WebP vía VP8 (RFC 6386) para con pérdida o LZ77 + Huffman para sin pérdida
Comparación de tamaño antes/después en tiempo real con porcentaje de ahorro
Descarga a Web Worker vía OffscreenCanvas cuando soportado (procesamiento por lotes no bloqueante)
Metadatos EXIF eliminados por defecto por privacidad (JEITA CP-3451X Exif 2.32) — opt-in preserveExif disponible

Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).

Fuentes (5)

Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT license) — widely-used JS image compressor: Canvas-based for JPG/WebP/BMP, UZIP-based DEFLATE for PNG; supports OffscreenCanvas + Web Worker.
WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/jpeg', quality) for JPG re-encoding, toBlob('image/webp', quality) for WebP — universal Chrome/Edge/Firefox 96+, Safari WebP needs polyfill).
ITU-T (CCITT) Study Group VIII & ISO/IEC JTC 1/SC 29/WG 10 (JPEG) (1992). Information technology — Digital compression and coding of continuous-tone still images. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — DCT + Huffman quantisation per Annex K underlies JPG quality slider.
W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — PNG uses RFC 1951 DEFLATE (LZ77 + Huffman); browser-image-compression's UZIP path re-applies DEFLATE losslessly with optimised filter selection.
Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024) — WebP container; lossy mode VP8 (RFC 6386 Bankoski et al., Nov 2011) accepts quality 1–100; lossless mode preserves pixels exactly.

Son las especificaciones del W3C, ISO/IEC, ITU-T e IETF que la herramienta implementa o sobre las que se apoya. Localízalas en w3.org, iso.org, itu.int o datatracker.ietf.org.

Guías relacionadas

Patrocinado

Por Marco B. · Última verificación mayo 2026 — corre en tu navegador