Skip to content

Redimensionar Imágenes en Lote online

En el navegador — sin subida
Última verificación mayo 2026 — corre en tu navegador

Redimensionador en Lote — Remuestreo Lanczos por Lote vía Canvas + File API

Arrastra una carpeta entera de fotos y redimensiónalas a un ancho objetivo en una pasada, con la proporción preservada por archivo. La herramienta itera la interfaz FileList del File API de WHATWG (html.spec.whatwg.org/#filelist) sobre cada archivo seleccionado, decodifica cada uno vía los decoders integrados del navegador (JPG / PNG / WebP / AVIF) y ejecuta la misma pipeline drawImage() del Canvas 2D Context de WHATWG que usa la herramienta resize-image para una imagen — imageSmoothingQuality = 'high' mapea a un kernel clase Lanczos (Duchon 1979, Journal of Applied Meteorology 18(8):1016-1022) en Chrome / Edge / Safari / Firefox. Cada resultado se serializa vía HTMLCanvasElement.toBlob() de vuelta al formato origen y se expone como href descargable vía URL.createObjectURL — el nombre de archivo original se conserva así que tu esquema de nombres sobrevive el lote. Entradas JPG, PNG y WebP pueden mezclarse en un mismo lote; el paso de remuestreo normaliza todo a sRGB a precisión de 8 bits según IEC 61966-2-1:1999 (orígenes HDR se mapean tonalmente a SDR durante el drawImage). Como toda la pipeline es del lado navegador, el único cuello de botella es tu CPU y memoria — no la conexión de subida. Los archivos nunca salen del dispositivo.

Relacionado: Redimensionar Imagen Redimensionar Redes Conversión Masiva Comparar Imágenes Filtros de Imagen Comprimir Imagen

Cómo redimensionar en lote

  1. Arrastra varias imágenes a la herramienta o haz clic para seleccionar una carpeta vía el input multi-selección del File API de WHATWG.
  2. Introduce el ancho objetivo en píxeles. Los altos se calculan por archivo como round(alto_origen × ancho_objetivo / ancho_origen) para que cada imagen mantenga su proporción nativa.
  3. El navegador itera la FileList y ejecuta drawImage() con imageSmoothingQuality = 'high' (kernel clase Lanczos) en cada archivo, serializando el resultado vía toBlob() en el formato origen.
  4. Espera al lote. Los escritorios modernos manejan cientos de fotos por lote; los dispositivos móviles topan más bajo conforme la presión de memoria sube.
  5. Descarga los archivos uno a uno o todos a la vez. Los archivos originales en disco nunca se modifican.

Casos de uso comunes

  • Reescalar un lote de fotos de producto para una tienda online y que todas las miniaturas tengan un ancho exacto en píxeles (p. ej. 600 px) para la rejilla de imágenes del CMS.
  • Preparar una carpeta de imágenes de blog a 1200 px de ancho antes de subir a un CMS con presupuesto de peso por imagen.
  • Reducir tomas de cámara para un portfolio fotográfico que sirve variantes responsive 1× / 2× / 3× srcset.
  • Normalizar librerías tras mezclar exportaciones de distintas cámaras y modelos de móvil (dimensiones de origen variadas reducidas a un único ancho objetivo).
  • Generar miniaturas de ancho consistente para un catálogo de comercio electrónico sin trabajo manual archivo por archivo en un editor de escritorio.

Preguntas frecuentes

¿Hay límite de cuántas imágenes puedo reescalar?

No hay límite fijo — el rendimiento depende de tu navegador, memoria del dispositivo y tamaño de los archivos origen. Los escritorios modernos manejan cientos de fotos por lote; los móviles topan más bajo conforme el heap del navegador se llena de ImageBitmaps decodificados. Como todo corre local, no hay timeout de servidor — el lote terminará tarde o temprano mientras la memoria lo permita.

¿Mantiene la proporción?

Sí. Tú fijas el ancho objetivo y la herramienta calcula alto_objetivo = round(alto_origen × ancho_objetivo / ancho_origen) por archivo individualmente, así retratos y paisajes en el mismo lote reciben cada uno su dimensión emparejada correcta. Ninguno se estira ni se aplasta.

¿Puedo mezclar formatos en el mismo lote?

Sí. JPG (ITU-T T.81 / ISO/IEC 10918-1), PNG (W3C 2ª Edición / ISO/IEC 15948:2004) y WebP (RFC 9649 Zern, Massimino, Alakuijala — noviembre de 2024) pueden ir todos en el mismo lote. La herramienta lee el MIME de cada origen y re-codifica vía Canvas toBlob() al mismo tipo, así la extensión con la que empezaste es la extensión con la que terminas.

¿Qué algoritmo de remuestreo usa cada archivo?

El mismo Canvas drawImage() con imageSmoothingQuality = 'high' que usa la herramienta resize-image para una imagen — Chrome / Edge / Safari / Firefox mapean 'high' a un kernel clase Lanczos (Duchon 1979) que es el filtro de reducción estándar de la industria (también lo que usa Image.Resampling.LANCZOS de Pillow; ANTIALIAS era un alias de LANCZOS hasta su retirada en Pillow 10.0.0, 1 de julio de 2023). Cada archivo del lote recibe el filtro idéntico; la única variación por archivo es la ratio de dimensión origen-a-objetivo.

¿Se suben mis imágenes?

No. El navegador maneja todo a través del File API y el Canvas 2D Context de WHATWG. Ningún archivo sale del dispositivo — la pestaña Network de DevTools muestra cero peticiones de subida durante el lote. Los resultados descargables se exponen como hrefs URL.createObjectURL desde los Blobs en memoria, no desde un servidor.

Qué te aporta el lote frente al redimensionado por archivo — y la restricción solo-local

El redimensionado por lotes resuelve tres problemas que el flujo por archivo no resuelve: (1) consistencia. Un sistema de diseño o un presupuesto de imagen de CMS suele requerir todas las imágenes al mismo ancho objetivo (p. ej. 1200 px); hacer 200 fotos una a una invita al error humano en el campo de dimensión. La herramienta de lote aplica la llamada drawImage(width, height) idéntica a cada archivo, garantizando que el ancho de salida sea exactamente el que escribiste. (2) preservación de formato por archivo. Lotes mixtos (fotos de producto JPG + logos PNG + banners WebP) viajan por el canvas correctamente porque la herramienta lee el MIME de cada origen y re-codifica vía toBlob() al mismo tipo — JPG vía tablas de cuantización del Anexo K (ITU-T T.81), PNG vía DEFLATE (RFC 1951 Deutsch, mayo de 1996), WebP vía codificación de keyframe VP8 (RFC 6386 + RFC 9649). La matemática de preservación de proporción corre por archivo: alto_objetivo = round(alto_origen × ancho_objetivo / ancho_origen), así retratos y paisajes en el mismo lote reciben cada uno su dimensión emparejada correcta. (3) privacidad a escala. Subir 200 fotos en alta resolución a un redimensionador en servidor implica 200 transferencias ida y vuelta y 200 ocasiones para que el servicio registre, cachee o entrene con tus datos. La pipeline local del navegador lo mantiene todo en la memoria de la pestaña; el único coste es el tiempo de CPU y unos GB de heap durante el lote. Los límites prácticos dependen del dispositivo — los escritorios modernos manejan cientos de fotos por lote; los móviles topan más bajo conforme la presión de memoria sube. Las descargas salen una a una o vía un bundle 'descargar todo'; los archivos originales en disco nunca se modifican.

  • Bucle de lote itera la FileList del File API de WHATWG (html.spec.whatwg.org/#filelist) — arrastrar y soltar o input múltiple
  • Canvas drawImage por archivo con imageSmoothingQuality = 'high' (kernel clase Lanczos, Duchon 1979)
  • Matemática de proporción por archivo: alto_objetivo = round(alto_origen × ancho_objetivo / ancho_origen)
  • Lotes mixtos: JPG (ITU-T T.81 Anexo K), PNG (DEFLATE RFC 1951), WebP (VP8 RFC 6386 / RFC 9649) van y vuelven en su formato origen
  • Nombres de archivo originales preservados al descargar vía URL.createObjectURL
  • Opera en sRGB (IEC 61966-2-1:1999) a precisión de 8 bits; orígenes HDR mapeados tonalmente durante el resize
  • Límite práctico cientos de fotos por lote en escritorio, menor en móvil (limitado por CPU + memoria, no por subida)
  • Lado navegador vía WHATWG Canvas + File API — los archivos nunca salen del dispositivo

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

Fuentes (11)
  • WHATWG (live). HTML Living Standard — Canvas 2D Context: drawImage() + imageSmoothingQuality. html.spec.whatwg.org/#dom-context-2d-drawimage — same Canvas resampling pipeline applied per file in the batch; imageSmoothingQuality 'high' for downscaling, 'low' for nearest-neighbour-style fast resize.
  • Duchon, C. E. (1979). Lanczos Filtering in One and Two Dimensions. Journal of Applied Meteorology, 18(8):1016-1022 (August 1979) — Lanczos resampling reference for the per-image high-quality downscale path.
  • WHATWG (live). HTML Living Standard — File API + FileList + drag-and-drop interfaces. html.spec.whatwg.org/#filelist + w3.org/TR/FileAPI/ — browser-side multi-file selection (input type=file multiple, drag-and-drop DataTransfer.files) iterated client-side without upload.
  • WHATWG (live). HTML Living Standard — HTMLCanvasElement.toBlob() + URL.createObjectURL. html.spec.whatwg.org/#dom-canvas-toblob + url.spec.whatwg.org/#dom-url-createobjecturl — per-file output Blob serialised in the browser; createObjectURL exposes the resized result as a downloadable href without server round-trip.
  • Python Imaging Library (PIL Fork) — Pillow contributors (2023). Pillow 10.0.0 — Image.Resampling enum. pillow.readthedocs.io/en/stable/releasenotes/10.0.0.html — industry reference for batch image processing resampling filters (NEAREST / BILINEAR / BICUBIC / LANCZOS).
  • 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 — JPG re-encoding via Annex K quantisation tables for each resized JPG file in the batch.
  • W3C (PNG Working Group) (2003). Portable Network Graphics (PNG) Specification (Second Edition). W3C Recommendation 10 November 2003 / ISO/IEC 15948:2004 — PNG re-encoding for each resized PNG file in the batch; lossless DEFLATE compression preserves the resampled pixels exactly.
  • Deutsch, P. (1996). DEFLATE Compressed Data Format Specification version 1.3. RFC 1951, IETF (May 1996, Aladdin Enterprises — LZ77 + Huffman; 32 KB sliding window) — PNG IDAT compression algorithm applied per file in the batch.
  • Zern, J., Massimino, P., & Alakuijala, J. (Google LLC) (2024). WebP Image Format. RFC 9649, IETF (November 2024, Informational) — WebP re-encoding for each resized WebP file in the batch; lossy mode (VP8 keyframes) and lossless mode (LZ77 + Huffman/prefix coding) both round-trip cleanly through Canvas toBlob('image/webp', quality).
  • Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., & Xu, Y. (Google Inc.) (2011). VP8 Data Format and Decoding Guide. RFC 6386, IETF (November 2011, Informational) — VP8 keyframe bitstream used by WebP lossy mode in the batch re-encoding pipeline.
  • International Electrotechnical Commission (IEC) (1999). Multimedia systems and equipment — Colour measurement and management — Part 2-1: Default RGB colour space — sRGB. IEC 61966-2-1:1999 — default Canvas 2D colour space; mixed-format batches (JPG + PNG + WebP) are normalised to sRGB during the canvas resampling step.

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.

Patrocinado

Por ·