ToolBox Image — Por qué creamos ToolBox Image para que funcione completamente en tu navegador

La mayoría de las herramientas gratuitas de imágenes en línea funcionan igual: subes un archivo a su servidor, el servidor lo procesa y descargas el resultado. Ese modelo es simple de construir, pero tiene costos ocultos: tu privacidad, sus facturas de servidor y límites en el tamaño de archivo y rendimiento.

ToolBox Image adopta un enfoque diferente. Toda la aplicación — decodificación, codificación, compresión, redimensionamiento, conversión de formato — se ejecuta en tu navegador. No hay ningún servidor al que subir archivos. Tus imágenes nunca salen de tu dispositivo. Esta arquitectura fue una elección deliberada y moldeó cada decisión que tomamos sobre el producto.

¿Por qué el enfoque basado en el navegador?

La alternativa obvia es una arquitectura tradicional de servidor. Subes una imagen, el servidor la procesa con una herramienta como ImageMagick o Sharp y devuelve el resultado. Esto funciona, pero crea una serie de problemas difíciles de resolver:

• Privacidad. Los usuarios tienen que confiar en que no almacenarás, analizarás o filtrarás sus imágenes. Para documentos sensibles — imágenes médicas, maquetas de diseño, fotos personales — esa confianza es difícil de ganar.
• Costo. Cada compresión se ejecuta en tu infraestructura. Cuanto más éxito tengas, más pagas. Esto crea presión para limitar tamaños de archivo, añadir colas o introducir niveles de pago.
• Latencia. Subir un archivo de 100 MB en una conexión lenta lleva minutos antes de que comience el procesamiento. Para usuarios en regiones con mala conectividad, la herramienta es efectivamente inutilizable.
• Escalabilidad. Un solo servidor puede manejar docenas de compresiones concurrentes. ¿Pero qué pasa con miles? Necesitas grupos de autoescalado, balanceadores de carga, endpoints CDN — todo lo cual añade complejidad y costo.

El modelo basado en navegador resuelve todo esto de una vez. El procesamiento es gratuito (los ciclos de CPU del usuario), privado (ningún dato sale del dispositivo) e infinitamente escalable (cada usuario aporta su propio hardware).

Cómo funciona: WebAssembly y Web Workers

Hace diez años, ejecutar códecs de imagen en el navegador era imposible. Hoy, WebAssembly nos permite compilar bibliotecas de C y Rust directamente a un formato que el navegador puede ejecutar a velocidad casi nativa. Compilamos mozJPEG de Mozilla, libwebp de Google y el codificador AVIF libaom — todos escritos en C — a WebAssembly. El navegador los ejecuta tan eficientemente como si estuvieran instalados de forma nativa.

Pero la codificación de un solo hilo es lenta para lotes grandes. Ahí es donde entran los Web Workers. Cada worker se ejecuta en un núcleo de CPU independiente, y generamos tantos workers como núcleos tenga el dispositivo. En un portátil moderno con 8 núcleos, eso significa 8 imágenes comprimiéndose simultáneamente. Un lote de 200 fotos que llevaría minutos en un solo hilo termina en segundos.

Lo que sacrificamos

El enfoque basado en el navegador no es gratuito. La concesión más significativa es la memoria. La pestaña del navegador tiene acceso a la RAM del dispositivo, pero que una sola pestaña se bloquee porque una imagen superó la memoria disponible es una mala experiencia. Limitamos los archivos individuales a 100 MB y los lotes a 200 archivos para mantenernos dentro de límites seguros.

También sacrificamos funciones del lado del servidor como almacenamiento persistente, entrega de correos electrónicos y análisis. No hay base de datos de imágenes comprimidas, no hay boletín informativo, no hay registro de qué formatos prefieren los usuarios. Esto es filosóficamente coherente con nuestra postura de privacidad, pero significa que no podemos ofrecer funciones como "compresiones recientes" o "ajustes guardados entre sesiones".

Qué sigue

El navegador se está convirtiendo en un entorno de ejecución legítimo para aplicaciones sensibles al rendimiento. A medida que WebAssembly obtenga recolección de basura, subprocesos y soporte SIMD, más partes de la pila de aplicaciones pueden moverse al lado del cliente. Estamos explorando WebGPU para un procesamiento de píxeles aún más rápido y la API de Acceso al Sistema de Archivos para una integración perfecta de carpetas.

Por ahora, el compresor está activo y procesa miles de imágenes al día — todas permaneciendo exactamente donde deben estar.