Las herramientas de archivos en el navegador hacen el trabajo dentro de la página y no en un servidor. Tu archivo lo lee el File API del disco, lo procesa un motor WebAssembly como qpdf o FFmpeg que se ejecuta en la pestaña, y se escribe de vuelta como descarga. No existe ningún paso de subida, así que no se envía nada.
La arquitectura tiene tres partes. Las APIs de File y Blob mueven bytes entre tu disco y la página sin un viaje de ida y vuelta por la red. WebAssembly ejecuta motores que originalmente se escribieron para el escritorio, y por eso los resultados coinciden con una herramienta de escritorio en lugar de con una aproximación web simplificada. Canvas, Web Workers y MediaRecorder cubren las tareas que necesitan dibujo, procesamiento en segundo plano o una cámara. El intercambio es que la primera ejecución descarga el motor, y todo tiene que caber en la memoria de una pestaña.
La mayoría de la gente conoce esta idea por una línea de privacidad en una página de herramientas: los archivos nunca salen de tu dispositivo. Esa frase es verdadera o no lo es, y lo decide la arquitectura y no la intención. Esta guía explica qué puede ejecutar realmente hoy un navegador, por qué desaparece el paso de subida cuando se construye así y los costes que conlleva.
Compresor de imágenes
Un ejemplo concreto. Canvas y OxiPNG se ejecutan en la pestaña, los tamaños antes y después se muestran uno junto al otro, y el archivo nunca se sube.
Dos arquitecturas: el viaje de ida y vuelta al servidor y la pestaña local
La mayoría de los convertidores online siguen la misma forma. Tu navegador envía el archivo a un servidor con una subida HTTP, el servidor ejecuta una herramienta como ImageMagick o un FFmpeg sin interfaz, y vuelve un enlace de descarga. El trabajo es real y a menudo rápido, pero el archivo tiene que salir de tu máquina para que ocurra, y se queda en esa máquina todo el tiempo que el operador lo conserve.
Una herramienta en el navegador mantiene los mismos pasos y elimina el servidor. Leer el archivo, ejecutar el motor y escribir el resultado ocurren en la pestaña. Eso no es una pequeña variación del modelo de subida. Elimina toda una clase de problemas, porque no hay transferencia que interceptar, ni cola en la que esperar, ni ventana de retención que leer.
| Paso | Herramienta basada en servidor | Herramienta en el navegador |
|---|---|---|
| Leer el archivo | Copiado en su almacenamiento | Leído por el File API, se queda en local |
| Procesamiento | Su CPU, normalmente en cola | Tu CPU, dentro de la pestaña |
| Resultado | Un enlace de descarga que caduca | Una descarga Blob, lista de inmediato |
| Quién puede leer el archivo | Cualquiera con acceso a su almacenamiento | Solo tú |
Qué ejecuta realmente el navegador
Un breve recorrido por la pila técnica, porque estas capacidades son lo que hace posible la promesa de privacidad, y no una capa de marketing añadida por encima.
WebAssembly lleva los motores de escritorio a la pestaña
WebAssembly es un formato binario compacto que se ejecuta a una velocidad cercana a la nativa dentro de una máquina virtual aislada. Los motores escritos en C, C++ o Rust se compilan a él y se envían como archivos normales: qpdf para el cifrado de PDF, FFmpeg para vídeo y audio, Tesseract para el reconocimiento óptico de caracteres, pdf-lib para construir y editar PDF, y OxiPNG para la optimización sin pérdida de PNG. PDF.js se encarga del renderizado de PDF y la extracción de texto. Como son los mismos motores que se usan en el escritorio, la salida no es una aproximación web: un vídeo codificado por la compilación de FFmpeg en tu pestaña es la salida de FFmpeg.
Canvas y el flujo de trabajo de imagen
Las imágenes son la única categoría que no necesita WebAssembly. La API de Canvas expone la misma superficie de dibujo que usa un editor de imágenes nativo. createImageBitmap descodifica un archivo, un canvas contiene los píxeles y toBlob codifica el resultado de vuelta a PNG, JPEG, WebP o AVIF. Recortar, redimensionar, poner marca de agua y convertir formatos son todas operaciones de píxeles sobre esa superficie. La Compresor de imágenes lo combina con OxiPNG para la salida PNG, que recomprime el archivo sin pérdida en lugar de tirar la calidad.
Los Web Workers mantienen viva la interfaz
El trabajo pesado en el hilo principal congela la página, así que las tareas largas se ejecutan en un Web Worker, un hilo en segundo plano sin acceso al DOM. Las herramientas de vídeo entregan el trabajo a FFmpeg dentro de un worker y reciben de vuelta líneas de registro y eventos de progreso, y por eso la barra de progreso sigue moviéndose mientras el codificador está ocupado. Tesseract sigue el mismo patrón. Cabe destacar que la configuración de OCR de aquí usa una compilación del motor de un solo hilo, así que no necesita las cabeceras de SharedArrayBuffer que muchas herramientas WebAssembly requieren del servidor.
File y Blob mueven los bytes
El File API es lo que sustituye a la subida. Cuando sueltas un archivo en la página, JavaScript recibe un objeto File, y file.arrayBuffer() lee sus bytes en memoria cuando se piden. El resultado es un Blob, que puede convertirse en una URL local temporal o entregarse directamente a una descarga. Los bytes viajan del disco a la memoria y de vuelta, y no hay ninguna ruta de código en ese bucle que hable con la red. Esto también explica por qué una herramienta en el navegador no tiene límite de tamaño de subida impuesto por un servidor, solo el límite de memoria del dispositivo.
Por qué el procesamiento local significa que no se sube nada
La afirmación es fácil de enunciar y fácil de verificar. Subir es una petición de red que lleva tu archivo, y una herramienta en el navegador nunca la hace, porque no hay nada al otro lado que la necesite. Las únicas peticiones que hace una página como esta son para su propio código y sus recursos: el HTML, la hoja de estilos, el motor en el primer uso y la fuente.
No tienes que fiarte de eso. Abre las herramientas de desarrollador del navegador, cambia al panel de red, límpialo, luego procesa un archivo y observa. Las peticiones que aparecen llevan código y recursos. Ninguna de ellas lleva tu documento, y si te desconectas de la red después de que el motor se haya cargado, el procesamiento sigue funcionando. Hay una guía más larga, paso a paso, sobre comprobar si una herramienta sube tu archivo si quieres el procedimiento completo.
| Petición que verás | Qué conlleva |
|---|---|
| La página, su CSS y su JavaScript | Código del sitio, no tu archivo |
| El motor, en el primer uso | Una herramienta compilada, almacenada en caché después |
| Fuentes web | Una tipografía |
| Script de analítica | Una vista de página, no los bytes del archivo |
La última fila importa porque es la fuente habitual de falsas alarmas. La analítica se carga en la página e informa de que se vio una página, no del contenido de tu documento. Este sitio carga Google Tag Manager, y por eso el panel de red muestra un script de Google. Esa petición informa de una vista de página, y no es una transferencia de archivo.
Qué pagas por ello
El procesamiento local no es gratis, y la versión honesta del argumento merece exponerse claramente. Aparecen tres costes, y un cuarto punto explica dónde se detiene el navegador.
- La primera ejecución descarga. Cada motor se obtiene una vez: unos 30 MB para el núcleo de FFmpeg detrás de las herramientas de vídeo y audio, unos 6.7 MB para el motor de OCR y los datos de inglés, unos 1.3 MB para el motor de PDF y unos 1.4 MB para el worker de PDF.js usado para las vistas previas de página. Nada de eso es tu archivo, y todo se almacena en caché, pero un arranque en frío con una conexión lenta es un arranque lento.
- La memoria es el techo. Todo lo que el motor lee y escribe vive en una sola pestaña. Una herramienta de escritorio transmite un archivo grande desde el disco, mientras que una pestaña del navegador lo mantiene, así que un vídeo o un PDF enorme puede agotar la memoria antes de terminar. Algunas herramientas indican un tope duro por esta razón, como el límite de 50 MB de la herramienta de desbloqueo de PDF.
- Un servidor puede ser más rápido. La codificación de vídeo depende de la CPU, y una máquina dedicada con más núcleos y una caché más caliente superará a una pestaña de portátil. La compilación para navegador también depende de la codificación por software en lugar de un codificador por hardware, así que no obtiene la aceleración por GPU que una compilación nativa puede usar.
- Algunas tareas todavía necesitan un servidor. La eliminación de fondos, el borrado de objetos y la mejora generativa de imágenes dependen de modelos grandes que ningún presupuesto razonable de descarga cubre. Esos tres los gestiona Cloud AI y sí suben la imagen. Todo lo demás en el sitio es local.
Para un documento de unos pocos megabytes o un clip de un minuto, ninguno de estos costes se nota, y el intercambio compra privacidad y ausencia de cuotas. Para una grabación 4K de dos horas, una herramienta de escritorio o una tarea de servidor es la mejor opción, y la respuesta honesta es decirlo.
El mismo patrón en todo el conjunto de herramientas
El página de inicio agrupa las herramientas en cinco secciones, y la arquitectura es la misma en cada una. El trabajo con PDF se ejecuta con qpdf, pdf-lib y PDF.js. Por ejemplo Combinar PDF combina archivos con pdf-lib, mientras que PDF a texto extrae texto con PDF.js y recurre a Tesseract solo para páginas escaneadas. El trabajo de imagen se ejecuta con Canvas y OxiPNG. El vídeo y el audio se ejecutan con FFmpeg, con Compresor de vídeo y las herramientas de audio compartiendo un solo motor. El OCR se ejecuta con Tesseract. Las tres herramientas Cloud AI son la excepción, y el sitio las etiqueta como tales en lugar de difuminar la línea.
La conclusión práctica es que puedes razonar sobre cualquier herramienta de la misma manera. Si nombra un motor real y lo ejecuta en la pestaña, el archivo se queda donde está. Si necesita un modelo más grande del que un navegador puede descargar, dirá que sube archivos, y debería decirlo en la página y no en una nota al pie.
