Conversor de imágenes por lotes gratuito

Convierte varias imágenes a la vez entre PNG, JPG y WebP. Ajusta la calidad, compara los tamaños de archivo y descárgalo todo al instante.

Tus datos nunca salen de tu dispositivo
Suelta las imágenes aquí o haz clic para examinar (JPEG, PNG, WebP, GIF, BMP, TIFF)

Procesando…

Acerca de la conversión de formato de imagen

Cada formato de imagen tiene su uso. PNG es sin pérdida, ideal para gráficos; JPG es perfecto para fotos y ofrece archivos más pequeños; y WebP ofrece compresión moderna con alta calidad. La conversión por lotes ahorra tiempo al procesar varios archivos.

JPEG (1992), el formato fotográfico

El Joint Photographic Experts Group se formó en noviembre de 1986 en Parsippany, Nueva Jersey, con miembros extraídos de ISO TC97 SC2/WG8 y el grupo CCITT SGVIII. Tras seis años de trabajo de comité, el texto de la Recomendación T.81 del CCITT se aprobó el 18 de septiembre de 1992, con el texto idéntico publicado como Norma Internacional ISO/IEC 10918-1 en 1994. Esa publicación de dos documentos es el momento en que JPEG se convirtió en el formato fotográfico del mundo. El núcleo matemático es la transformada coseno discreta aplicada a bloques de 8×8 píxeles: cada bloque se descompone en una suma de ondas coseno, los componentes de alta frecuencia a los que la visión humana es menos sensible se cuantifican más agresivamente que los de baja frecuencia que el ojo nota primero. El control de «calidad» orientado al usuario es exactamente eso, un multiplicador sobre la tabla de cuantificación. Mayor calidad significa divisores más pequeños, más precisión, archivos más grandes. Menor calidad significa más ceros tras la cuantificación, mejor codificación entrópica y un archivo más pequeño a costa de bloqueo y artefactos de ringing visibles. JPEG es lossy por diseño: no existe configuración de calidad en la que un round-trip JPEG sea matemáticamente idéntico a su entrada. Para fotografías de escenas naturales (caras, paisajes, comida, cualquier cosa con gradientes suaves y tono continuo) esto es irrelevante; la pérdida vive bajo el umbral de sensibilidad de la visión humana y el archivo es una fracción del tamaño que produciría un formato sin pérdida. Para gráficos con bordes duros, texto, line art o grandes áreas de color plano, JPEG es la elección equivocada: el mismo DCT mancha los bordes nítidos con artefactos de ringing («ruido de mosquito») y fronteras en bloques entre celdas 8×8.

PNG (octubre 1996 / enero 1997), el formato gráfico sin pérdida

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 de junio de 1987), el sobreviviente de la animación y la saga de patentes

Steve Wilhite, líder de ingeniería en CompuServe, presentó GIF el 15 de junio de 1987 para resolver un problema específico: cómo compartir imágenes en color a través de los lentos módems del servicio en línea de CompuServe sin que los archivos se comieran la asignación mensual del usuario. Su equipo eligió el algoritmo de compresión Lempel-Ziv-Welch (LZW) y limitó la paleta de colores a 256 entradas. Lo que CompuServe no sabía en 1987 era que LZW había sido patentado por Sperry Corporation (más tarde Unisys) en 1985. La cuestión de patentes estalló a la vista pública a finales de 1994. Unisys anunció en 1995 que cobraría regalías por software que usara el algoritmo (incluyendo GIF, TIFF y PDF) a tasas de aproximadamente 0,45 % a 0,65 % de los ingresos. La comunidad open-source de la web respondió con dos acciones paralelas: la campaña «Burn All GIFs» y el diseño de PNG, explícitamente para ser un reemplazo de GIF libre de patentes. La patente estadounidense de Unisys expiró en junio de 2003; las patentes correspondientes en otras jurisdicciones expiraron hasta 2004. Para 2004, GIF estaba libre de patentes por primera vez en su historia. GIF sobrevivió por una característica que PNG (originalmente) no tenía: animación. Soporta una secuencia de frames con tiempos de retardo por frame y un índice de paleta transparente, lo que lo convierte en la lingua franca de las imágenes de reacción en bucle y las banderas web. La paleta de 256 colores es una limitación real para fotos, y la transparencia de 1 bit produce bordes feos al superponer sobre un fondo coloreado, pero para animaciones cortas en bucle de contenido estilo cartoon, GIF aún gana en soporte universal.

BMP (mayo 1990) y TIFF (otoño 1986), los reductos heredados

BMP (Bitmap, también llamado Windows Device Independent Bitmap) se incorporó en Windows 3.0, lanzado el 22 de mayo de 1990, donde se convirtió en el estándar para almacenamiento de bitmap en el entorno gráfico Windows. Es esencialmente sin compresión, el array de píxeles crudo, opcionalmente alineado a límite de 4 bytes por fila, con una pequeña cabecera al frente. Un BMP 1920×1080 de 24 bits es de unos 6,2 MB; la misma imagen como JPEG calidad 85 podría ser 200 KB. El papel de BMP en 2026 es esencialmente como formato de intercambio heredado y el formato que históricamente usaron las capturas de pantalla de Windows. TIFF (Tagged Image File Format) fue publicado por primera vez por Aldus Corporation en otoño de 1986 (Revisión 3.0); la Revisión 6.0 en junio de 1992 añadió color CMYK y YCbCr y JPEG-en-TIFF. Adobe adquirió Aldus en 1994 y ahora posee el copyright. TIFF es único en ser un formato contenedor en lugar de un único esquema de codificación, un único archivo TIFF puede contener múltiples imágenes (TIFF multipágina, común para fax y capítulos de libros escaneados), usar cualquiera de varios métodos de compresión (ninguno, LZW, ZIP, JPEG, CCITT Grupo 3/4 para fax) y almacenar metadatos esencialmente arbitrarios a través de su estructura de campos etiquetados. Esta flexibilidad hace de TIFF el valor por defecto para flujos de prensa, escaneo y archivado de documentos; esencialmente nunca se usa para imágenes web. Su presencia en la lista de entrada es para usuarios convirtiendo fuentes destinadas a impresión o escaneadas en formatos web-friendly.

WebP (30 de septiembre de 2010), el formato web moderno

Google anunció WebP el 30 de septiembre de 2010 como un nuevo formato abierto para gráficos true-color comprimidos con pérdida en la web, produciendo archivos más pequeños que JPEG a calidad comparable. El formato se basa en la codificación de keyframe del códec de vídeo VP8, que Google había adquirido con la compra de On2 Technologies. Inicialmente WebP era solo lossy. El 18 de noviembre de 2011, Google anunció un modo de compresión sin pérdida y soporte para transparencia tanto en modos lossless como lossy; libwebp 0.2.0 alcanzó una implementación lossless estable el 16 de agosto de 2012. Según la documentación para desarrolladores de Google: las imágenes WebP lossless son aproximadamente 26 % más pequeñas que las mismas imágenes en PNG, y las imágenes WebP lossy son 25-34 % más pequeñas que JPEG comparables a calidad SSIM equivalente. Estas reducciones no son magia, provienen de un diseño de códec fundamentalmente más nuevo (codificación intra-frame predictiva, codificación entrópica aritmética moderna, transformaciones de color más inteligentes) que las bases de principios de los 1990 contra las que se diseñaron JPEG y PNG. El soporte del navegador fue una construcción lenta: Chrome 17 en febrero de 2012 (lossy), Chrome 23 en noviembre de 2012 (lossless). Apple aguantó la mayor parte de una década y finalmente añadió soporte WebP en Safari 14, que se lanzó con iOS 14 y macOS 11 Big Sur en septiembre de 2020. Esa fecha de septiembre de 2020 es el momento en que WebP se hizo prácticamente utilizable como formato web principal sin un fallback JPEG para usuarios de iPhone. La cobertura hoy es aproximadamente el 97 % del tráfico global, WebP ya no es un formato «moderno» con salvedades, es un por defecto.

Más allá de WebP: AVIF (febr. 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 fue lanzado el 19 de febrero de 2019 por la Alliance for Open Media (AOMedia, un consorcio de Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple). Es el perfil de imagen fija del códec de vídeo AV1, construido sobre el contenedor HEIF, y es actualmente el formato de imagen ampliamente desplegado que mejor comprime, a calidad visual equivalente, los archivos AVIF son típicamente 50 % más pequeños que JPEG y 20-30 % más pequeños que WebP. El soporte del navegador llegó en tres oleadas: Chrome 85 (agosto de 2020), Firefox 93 (octubre de 2021), Safari con iOS 16 (septiembre de 2022) y macOS Ventura (octubre de 2022). HEIC es el formato por defecto del iPhone desde iOS 11 en 2017, el contenedor HEIF con imágenes comprimidas HEVC, formalmente ISO/IEC 23008-12. La compresión es excelente (típicamente 50 % más pequeña que JPEG) pero HEVC tiene patentes, razón por la cual Chrome, Firefox y Edge no-Apple se niegan a decodificar HEIC nativamente. JPEG XL (ISO/IEC 18181, 2022) es el formato técnicamente excelente pero de nicho, puede recomprimir sin pérdida los JPEG existentes a aproximadamente 20 % más pequeños, soporta HDR, gama amplia, animación y decodificación progresiva, y está libre de patentes. Chrome quitó su flag experimental el 31 de octubre de 2022 (la «decisión Halloween»); Apple lanzó Safari 17 en septiembre de 2023 con JPEG XL nativo en macOS Sonoma, iOS 17 y visionOS. El formato es soportado nativamente en Safari 17+, detrás de un flag en Firefox y Chrome 145 (febrero de 2026), pero la entrega por defecto para tráfico general permanece pendiente. Este convertidor actualmente no emite AVIF, HEIC ni JPEG XL, están listados aquí para que pueda decidir si manejarlos aguas arriba.

Eligiendo el formato de salida correcto

La historia formato a formato anterior es una visita. La pregunta práctica es más corta: dada una imagen particular y un uso particular, ¿qué formato de salida es correcto?

Lo que el control de calidad realmente hace

El control de calidad va de 10 a 100 en pasos de 5. Detrás de ese único número hay una relación sorprendentemente no lineal entre calidad percibida y tamaño de archivo. Para JPEG, el consenso a través de la ingeniería de procesamiento de imágenes es que la calidad 75-85 es el sweet spot. A calidad 80, el tamaño del archivo cae 70-90 % desde una fuente sin comprimir con diferencia visual imperceptible a distancias normales de visualización en pantalla. La caída entre calidad 80 y 85 es brusca: una imagen de prueba representativa podría ir de 3,7 MB a calidad 80 a 6 MB a calidad 85, casi una duplicación sin mejora visible en una pantalla de teléfono o portátil. Calidad 75 es donde los artefactos comienzan a ser detectables en inspección cercana de detalles de alta frecuencia (bordes de texto, texturas finas). Calidad 90 y arriba es para JPEG de archivado donde el tamaño del archivo es irrelevante. El por defecto de 80 se sienta en el extremo bajo del sweet spot, apropiado para optimización web por lotes, donde el objetivo es enviar tan pocos datos como sea posible manteniendo imágenes que se vean aceptables. Para WebP, el por defecto de la API canvas toBlob('image/webp') es calidad 0,80; WebP a calidad 70 es generalmente tan visualmente limpio como JPEG a calidad 80. Para PNG, «calidad» es un nombre erróneo, PNG es siempre lossless en los datos de píxel. El control en esta herramienta no tiene efecto cuando se selecciona PNG como formato de salida. La lección crucial para procesamiento por lotes: una sola configuración de calidad rara vez es correcta para cada imagen en un lote mixto. Una carpeta de 50 fotos tomadas con la misma cámara en la misma iluminación probablemente puede guardarse toda a calidad JPEG 80 sin pérdida. Una carpeta mezclando capturas de pantalla, fotos, line art y logos no puede, un «convertir todo a JPG-80» de un solo botón convertirá las capturas de pantalla en ruido de mosquito ilegible. Divida la entrada en lotes separados cuando el contenido varíe.

Lossy vs lossless, la distinción más importante

Un codificador sin pérdida garantiza que la salida decodificada sea bit-idéntica a la entrada codificada. PNG es lossless. WebP-lossless es lossless. TIFF (en sus modos lossless) es lossless. La compensación es el tamaño de archivo: los codificadores sin pérdida no pueden explotar diferencias perceptuales imperceptibles y deben preservar todo. Una fotografía 1920×1080 como PNG lossless podría ser 5 MB; la misma foto como JPEG-calidad-85 es 200 KB. El PNG es bit-perfecto; el JPEG es visualmente equivalente. Un codificador lossy descarta información que el sistema visual humano es menos probable que note, detalle de alta frecuencia, fina variación de croma en colores saturados, la cuarta cifra significativa de cada gradiente. JPEG, WebP lossy y AVIF lossy todos hacen esto. Las implicaciones para un convertidor por lotes son concretas: lossless a lossless (PNG a PNG, o PNG a WebP-lossless) es genuinamente sin pérdida a través de cualquier número de conversiones; lossy a lossy a la misma calidad (JPEG-85 a JPEG-85) no es lossless, cada re-codificación aplica otro paso de cuantificación, repita 10 veces y el resultado está visiblemente degradado; lossy a lossless (JPEG a PNG) congela los artefactos existentes en su lugar pero no los re-degrada; lossless a lossy introduce compresión con pérdida en el momento de la conversión y no hay forma de recuperar el detalle descartado más tarde. Los usuarios a menudo vuelven a ejecutar una conversión esperando que sea un no-op. Fuera del caso lossless-a-lossless, no lo es.

EXIF, IPTC, XMP, y por qué esta herramienta los retira

Los archivos JPEG y HEIC de cámaras y teléfonos llevan un bloque EXIF, metadatos Exchangeable Image File Format incrustados en la cabecera de la imagen. EXIF incluye modelo de cámara, lente, ajustes de exposición, fecha y hora, versión de software, y lo más consecuente las coordenadas GPS de dónde se tomó la foto (si los servicios de localización estaban activados al momento de captura). Los metadatos IPTC añaden caption, byline, copyright y palabras clave. XMP, originalmente de Adobe, es un superconjunto basado en XML que subsume los formatos más antiguos y es lo que usan Lightroom y Photoshop. Las implicaciones de privacidad son significativas. Una foto tomada en un iPhone con localización activada incrusta coordenadas GPS precisas a unos pocos metros. Compartirla en un foro, en un adjunto de email, o vía un blog personal puede revelar la dirección de casa del fotógrafo, el colegio de su hijo, su lugar de trabajo, su ruta de senderismo. Las principales plataformas sociales (Facebook, Instagram, Twitter/X) retiran EXIF al subir antes de servir la imagen a otros usuarios, pero leen y almacenan los metadatos originales ellas mismas. Los foros más pequeños, blogs WordPress, Discord, clientes de email y transferencias directas de archivos dejan EXIF intacto. La re-codificación a través de la API canvas (el motor que usa esta herramienta) descarta por defecto todos los metadatos EXIF, IPTC y XMP. La salida es una imagen limpia sin procedencia incrustada, una característica de privacidad, y un efecto secundario del pipeline canvas (el canvas solo almacena datos de píxel; no tiene noción de metadatos que preservar). Los usuarios que quieren preservar metadatos (fotógrafos archivando datos de exposición, flujos de contenido donde el copyright debe viajar con el archivo) necesitan una herramienta diferente, típicamente convert de ImageMagick o una biblioteca dedicada consciente de EXIF. Este convertidor corta en el otro sentido: es metadata-stripping por diseño, lo que es exactamente lo que un usuario consciente de la privacidad quiere cuando envía imágenes a un foro donde no quiere que sus coordenadas GPS le sigan.

Fondos transparentes, la elección PNG-a-JPEG

PNG soporta un canal alpha por píxel: cada píxel tiene una opacidad de 0 (totalmente transparente) a 255 (totalmente opaco). JPEG no tiene canal alpha. Convertir un PNG con transparencia a JPEG fuerza una elección: ¿qué deberían convertirse los píxeles transparentes? El por defecto de la API canvas es componer contra negro transparente, así que el JPEG resultante resuelve los píxeles transparentes a negro opaco. Un logo sobre fondo transparente convertido PNG-a-JPEG sale con esquinas negras alrededor del logo, prácticamente nunca lo que el usuario quería. La mitigación es rellenar el canvas con un color de fondo elegido (blanco es el por defecto típico) antes de dibujar la imagen encima. Los usuarios que necesiten preservar la transparencia deberían elegir PNG o WebP como formato de salida. WebP soporta transparencia tanto en modos lossless como lossy, lo que lo hace la elección moderna cuando la fuente tiene transparencia y el destino necesita ser eficiente, un PNG de fondo transparente de 50 KB podría convertirse en un WebP lossy de fondo transparente de 12 KB preservando el canal alpha.

Cómo se ejecuta la conversión en tu navegador

La afirmación «todo se ejecuta en tu navegador» descansa en tres APIs de la Plataforma Web que solo recientemente se han vuelto lo suficientemente potentes como para hacer de un convertidor de imágenes por lotes un producto cliente-side creíble. APIs FileReader y Blob: cuando dejas archivos en la zona de subida, cada File es una subclase de Blob que expone ya sea readAsDataURL() (callback más antiguo) o file.arrayBuffer() (basado en Promise). Para imágenes específicamente, el camino más simple es construir una URL Blob con URL.createObjectURL(file) y asignarla a un nuevo elemento Image, dejando que el decodificador de imágenes incorporado del navegador maneje JPEG, PNG, GIF, WebP y BMP nativamente. La API Canvas: una vez que una Image está cargada, la conversión es una danza en dos pasos, dibujar con ctx.drawImage(img, 0, 0), luego leer el canvas de vuelta con canvas.toBlob(callback, type, quality). El parámetro type es una cadena MIME ('image/png', 'image/jpeg', 'image/webp'); el parámetro quality es un número entre 0 y 1 para formatos lossy. OffscreenCanvas y Web Workers: para lotes grandes, hacer todo el trabajo de canvas en el hilo principal bloquea la UI. La solución moderna es OffscreenCanvas, que expone operaciones de canvas en un contexto de worker y es ella misma transferible a un Web Worker vía postMessage sin copiar. El worker ejecuta el pipeline decodificar-rasterizar-codificar en un hilo separado, manteniendo la página responsiva. Juntas estas APIs hacen que un lote de 50 archivos se ejecute en segundos sin bloquear el scrolling o los clics de botones. JSZip (una biblioteca pura JavaScript con licencia MIT) maneja el empaquetado ZIP final enteramente en memoria antes de que el cuadro de diálogo de guardado del navegador se dispare. Sin subida, sin zip de servidor, sin archivo temporal en disco. Hace una década un convertidor de imágenes por lotes que se ejecutara en el navegador habría sido una curiosidad. El rendimiento WebAssembly, el paralelismo OffscreenCanvas, y la RAM de teléfono moderna (6-12 GB) y el conteo de núcleos (6-8 CPUs) han invertido esa imagen. El argumento de privacidad cierra el caso: los convertidores del lado del servidor requieren subir tus imágenes a una máquina de terceros, e incluso con una política de eliminación escrupulosa, la subida en sí es un evento de red que puede ser registrado, interceptado o comprometido. Un convertidor solo-navegador nunca envía un byte.

Preguntas frecuentes

¿Qué formatos de imagen se admiten?

El convertidor procesa la mayoría de los formatos habituales (JPG, PNG, GIF, WebP, BMP, TIFF) y convierte a PNG, JPG o WebP.

¿Puedo ajustar la calidad para JPG y WebP?

Sí. Usa el deslizador de calidad para ajustar la compresión (0-100). Valores más altos dan mejor calidad pero archivos más grandes.

¿Cómo descargar varios archivos?

Elige «Descargar todo en ZIP» para agrupar todas las imágenes convertidas en un único archivo ZIP, cómodo para descargar y guardar.

¿Por qué el límite es 50 archivos por lote?

Es un techo de memoria. Cada imagen tiene que decodificarse en RAM como datos de píxel crudos antes de que el canvas pueda re-codificarla. Una foto de iPhone de 12 megapíxeles se decodifica a unos 36 MB de datos de píxel (12 millones de píxeles × 3 bytes RGB, o 4 bytes RGBA). 50 de esas a la vez son 1,8 GB de memoria de trabajo. La mayoría de portátiles manejan eso cómodamente; los teléfonos más antiguos no. El tope de 50 archivos mantiene la página predecible a través de dispositivos. Para lotes más grandes, ejecuta la herramienta en rondas, digamos, 50 archivos, descargar, limpiar, soltar otros 50.

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

Sin tope duro, el límite es la memoria disponible de tu dispositivo. Una sola imagen de 50 MP se decodifica a unos 150 MB de datos de píxel, lo que funciona en un escritorio pero tendrá problemas en un teléfono más antiguo. Como regla general, archivos bajo 10 MB se convierten suavemente en esencialmente cualquier dispositivo; archivos sobre 50 MB ralentizarán o fallarán en móviles de gama baja. Si una conversión se congela, refresca la página y prueba el archivo en un lote más pequeño.

¿El convertidor retira los metadatos EXIF?

Sí, por diseño. El pipeline de re-codificación canvas solo almacena datos de píxel, así que los bloques de metadatos EXIF, IPTC y XMP (modelo de cámara, ajustes de exposición, coordenadas GPS, etiquetas de copyright, historial de edición) no sobreviven el round-trip. La salida es una imagen limpia sin procedencia incrustada, lo que es una victoria de privacidad cuando compartes fotos a foros o contactos de email donde no quieres que las coordenadas GPS te sigan. Si necesitas los metadatos preservados (fotógrafos archivando datos de exposición, flujos de contenido requiriendo etiquetas de copyright), esta es la herramienta equivocada, usa convert de ImageMagick o una biblioteca dedicada consciente de EXIF que preserve metadatos explícitamente.

¿Qué pasa con los fondos transparentes cuando convierto PNG a JPG?

JPEG no tiene canal alpha, así que los píxeles transparentes en el PNG fuente tienen que convertirse en algún color opaco en la salida JPEG. El comportamiento por defecto del canvas es componer contra un fondo coloreado (típicamente blanco). Un logo sobre un fondo PNG transparente convertido a JPEG perderá la transparencia y recogerá el relleno de fondo. Si la transparencia importa, elige PNG o WebP como formato de salida, ambos preservan alpha. WebP-lossy preserva transparencia a tamaños de archivo dramáticamente más pequeños que PNG y es la elección moderna para gráficos web transparentes.

¿Mis imágenes se suben a algún sitio?

No. Cada paso (selección de archivo, decodificación, re-codificación canvas, empaquetado ZIP, descarga) se ejecuta enteramente en tu navegador vía JavaScript. No hay procesamiento del lado del servidor. Puedes verificar abriendo la pestaña Network de DevTools de tu navegador mientras conviertes: no hay peticiones salientes llevando datos de imagen. La página es segura para capturas de pantalla sensibles, escaneos de documentos, fotos personales con metadatos de localización, o cualquier otra cosa que no querrías ver copiada al disco duro de un desconocido.

Herramientas relacionadas

PDF → HTML

Convierte PDF en HTML al instante.

Codificador Base64

Codifica imágenes en Base64.

Texto → CSV

Convierte datos al formato CSV.