Compresor JPG — Cuantización DCT según ITU-T T.81 Anexo K
JPEG (ITU-T T.81 aprobado 18 septiembre 1992 / ISO/IEC 10918-1:1994) usa cuantización DCT + Huffman con pérdida afinada para contenido fotográfico — descarta información visual que tu ojo menos probablemente echa en falta, cambiando fidelidad perfecta por reducción sustancial de tamaño. El slider de calidad (1–100) mapea directamente al escalado de tablas de cuantización del Anexo K: mayor calidad = pasos de cuantización más pequeños = más coeficientes DCT preservados = archivo más grande. Calidad 90+ deja fotos visualmente idénticas a sin pérdida; 75–85 es el punto dulce web según consenso de la industria; por debajo de 60 los artefactos de compresión (límites de bloques 8×8, ringing, banding) se vuelven notables en degradados y cielos. La salida es un JPEG estándar envuelto en JFIF v1.02 (Eric Hamilton, C-Cube Microsystems, 1 septiembre 1992) que abre en todas partes. Nota: recomprimir un JPG ya comprimido siempre introduce pérdida generacional adicional — el redondeo de cuantización se acumula con cada pasada.
Cómo comprimir un JPG
- Arrastra un archivo .jpg / .jpeg a la herramienta o haz clic para seleccionar — archivo suelto o lote.
- Baja el slider de calidad. 80–85 es el punto dulce web para fotos; 70 es agresivo pero a menudo aceptable.
- Observa el porcentaje de ahorro. Si los límites de bloques 8×8 o ringing se vuelven visibles, sube la calidad.
- Descarga la copia comprimida. Conserva el máster original si puedes necesitar re-exportar después (la re-compresión compone la pérdida).
Casos de uso comunes
- Optimizar fotos de producto e-commerce para que las páginas carguen más rápido — JPG calidad 85 típica, sin pérdida visible para compradores.
- Encajar fotos de viaje bajo límites de adjuntos de correo (10 MB Gmail / 25 MB Outlook) sin redimensionar.
- Reducir el peso de imágenes de posts de blog para mejor Core Web Vitals (Largest Contentful Paint) — calidad 80–85 típica.
- Aligerar fotos de móvil antes de respaldo en la nube (Google Photos, iCloud, Dropbox) — reducción típica de almacenamiento 40–70%.
Preguntas frecuentes
¿Puedo comprimir el mismo JPG dos veces?
Puedes, pero cada pasada añade artefactos. JPEG (ITU-T T.81, 1992) es con pérdida por diseño — el redondeo de cuantización se acumula con cada recodificación. Comprime siempre desde el máster original en vez de encadenar pasadas.
¿Qué calidad conviene por defecto para web?
75–85 es el punto dulce web estándar según consenso de la industria. Calidad 85 = reducción de tamaño 40–70% con artefactos que la mayoría de espectadores no notará. Calidad 70 = agresiva para páginas con muchas imágenes donde el peso total importa más que la fidelidad.
¿Esta herramienta redimensiona mi imagen?
No. La compresión solo recodifica píxeles — las dimensiones permanecen iguales. El slider de calidad controla el escalado Q-table T.81 Anexo K. Para dimensiones más pequeñas, usa primero bulk-resize o resize-image.
¿Sobrevivirán los metadatos EXIF de mi foto a la compresión?
Por defecto no — la recodificación Canvas elimina el APP1 EXIF de JPEG (JEITA CP-3451X / CIPA DC-X008-2019, Exif 2.32, mayo 2019). Default de privacidad. browser-image-compression tiene flag opt-in preserveExif.
¿Mi foto se sube a un servidor?
No. La compresión corre localmente en el Canvas en tu navegador — verificable en pestaña Network de DevTools (no se disparan peticiones de subida). Web Worker opcional vía OffscreenCanvas mantiene el hilo principal responsivo para procesamiento por lotes.
Por qué la recodificación JPEG siempre cuesta calidad — y cómo minimizar el coste
La cuantización JPEG es fundamentalmente no reversible. El codificador toma bloques de píxeles 8×8, aplica una Transformada Coseno Discreta para convertir valores de píxel espaciales en coeficientes de frecuencia, luego divide cada coeficiente por un valor de tabla de cuantización y redondea al entero más cercano. El redondeo es donde la información se descarta permanentemente. Cuando recodificas un JPEG: el decodificador reconstruye valores de píxel aproximados desde los coeficientes previamente cuantizados (introduciendo error de decodificación), luego el codificador aplica una tabla de cuantización (potencialmente distinta) y redondea de nuevo (introduciendo error adicional de codificación). Efectos compuestos: los límites de bloques 8×8 se afilan en cada pasada, el ringing se acumula cerca de bordes nítidos, los gradientes hacen banding progresivamente. El estudio clásico 'Why JPEG is like a photocopier' de Cloudinary documenta esta pérdida generacional empíricamente. Mejor práctica: comprime siempre desde el máster original en vez de encadenar pasadas de compresión. Si el máster ya es JPEG, comprimirlo una vez a calidad 80 típicamente produce pérdida invisible mientras comprimir el mismo JPEG dos veces a calidad 80 degrada visiblemente. La herramienta usa la librería browser-image-compression de amplio uso (Donaldcwl, licencia MIT) que enruta JPGs a través de Canvas toBlob('image/jpeg', quality), con descarga opcional a Web Worker vía OffscreenCanvas. Los metadatos EXIF (JEITA CP-3451X Exif 2.32) se eliminan por defecto por privacidad — el flag opt-in preserveExif retiene los marcadores APP1 si se necesita.
- Calidad 1–100 mapeada al escalado de tablas de cuantización ITU-T T.81 Anexo K
- Salida en contenedor JFIF v1.02 (Hamilton 1992) — abre en todas partes
- Metadatos EXIF eliminados por defecto (JEITA CP-3451X Exif 2.32) — beneficio de privacidad; preserveExif opt-in disponible
- Descarga a Web Worker vía OffscreenCanvas (procesamiento por lotes no bloqueante)
- Comparación de tamaño en tiempo real con porcentaje de ahorro antes de descargar
- Librería browser-image-compression (Donaldcwl, MIT)
Gratis. Sin registro. Sin subidas. Anuncios mediante AdSense (con consentimiento).
Fuentes (6)
- 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: Requirements and guidelines. ITU-T Recommendation T.81 (18 September 1992) / ISO/IEC 10918-1:1994 — Annex K quantisation tables map quality 1–100 to DCT coefficient scaling; lossy by design.
- Hamilton, E. (C-Cube Microsystems) (1992). JPEG File Interchange Format (JFIF) Version 1.02. 1 September 1992 — de facto JPEG container; APP0 marker for density (DPI) + thumbnail; preserved through Canvas re-encoding by toBlob('image/jpeg', quality).
- JEITA / CIPA (2019). Exchangeable image file format for digital still cameras: Exif Version 2.32. JEITA CP-3451X / CIPA DC-X008-2019 (revised 17 May 2019) — JPEG APP1 EXIF metadata; Canvas-based re-encoding strips EXIF by default; browser-image-compression preserves EXIF as opt-in option.
- WHATWG (live). HTML Living Standard — Canvas 2D Context + HTMLCanvasElement.toBlob(). html.spec.whatwg.org/#2dcontext (toBlob('image/jpeg', quality) where quality ∈ [0,1] maps to T.81 Annex K Q-table scaling; re-encoding always introduces additional generation loss).
- Donald (Donaldcwl) (live). browser-image-compression. npm package v2.0.2 (github.com/Donaldcwl/browser-image-compression, MIT) — Canvas-based JPG re-encoding pipeline used by this tool.
- Sneyers, J. (Cloudinary) (2016). Why JPEG is like a photocopier. cloudinary.com/blog/why_jpeg_is_like_a_photocopier (4 May 2016) — empirical study of JPEG generation loss across re-encoding passes; quantisation rounding accumulates each pass.
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.
Por Marco B. ·