ToolBox Image — Por que criamos o ToolBox Image para funcionar inteiramente no seu navegador

A maioria das ferramentas gratuitas de imagens online funciona da mesma forma: você envia um arquivo para o servidor deles, o servidor processa e você baixa o resultado. Esse modelo é simples de construir, mas tem custos ocultos — sua privacidade, as contas de servidor deles e limites no tamanho do arquivo e na taxa de transferência.

O ToolBox Image adota uma abordagem diferente. Todo o aplicativo — decodificação, codificação, compressão, redimensionamento, conversão de formato — é executado no seu navegador. Não há servidor para enviar arquivos. Suas imagens nunca saem do seu dispositivo. Essa arquitetura foi uma escolha deliberada e moldou cada decisão que tomamos sobre o produto.

Por que a abordagem baseada no navegador?

A alternativa óbvia é uma arquitetura tradicional de servidor. Você envia uma imagem, o servidor a processa com uma ferramenta como ImageMagick ou Sharp e envia o resultado de volta. Isso funciona, mas cria uma série de problemas difíceis de resolver:

• Privacidade. Os usuários precisam confiar que você não armazenará, analisará ou vazará suas imagens. Para documentos sensíveis — imagens médicas, maquetes de design, fotos pessoais — essa confiança é difícil de conquistar.
• Custo. Cada compressão é executada em sua infraestrutura. Quanto mais sucesso você tem, mais paga. Isso cria pressão para limitar tamanhos de arquivo, adicionar filas ou introduzir níveis pagos.
• Latência. Enviar um arquivo de 100 MB em uma conexão lenta leva minutos antes mesmo do processamento começar. Para usuários em regiões com conectividade ruim, a ferramenta é efetivamente inutilizável.
• Escala. Um único servidor pode lidar com dezenas de compressões simultâneas. Mas e milhares? Você precisa de grupos de autoescalonamento, balanceadores de carga, endpoints de CDN — tudo isso adiciona complexidade e custo.

O modelo baseado no navegador resolve tudo isso de uma vez. O processamento é gratuito (ciclos de CPU do usuário), privado (nenhum dado sai do dispositivo) e infinitamente escalável (cada usuário traz seu próprio hardware).

Como funciona: WebAssembly e Web Workers

Dez anos atrás, executar codecs de imagem no navegador era impossível. Hoje, o WebAssembly nos permite compilar bibliotecas C e Rust diretamente em um formato que o navegador pode executar em velocidade quase nativa. Compilamos o mozJPEG da Mozilla, o libwebp do Google e o codificador AVIF libaom — todos escritos em C — para WebAssembly. O navegador os executa tão eficientemente quanto se estivessem instalados nativamente.

Mas a codificação de thread único é lenta para lotes grandes. É aí que entram os Web Workers. Cada worker é executado em um núcleo de CPU separado, e geramos tantos workers quanto o dispositivo tem núcleos. Em um laptop moderno com 8 núcleos, isso significa 8 imagens comprimindo simultaneamente. Um lote de 200 fotos que levaria minutos em um único thread termina em segundos.

O que sacrificamos

A abordagem baseada no navegador não é gratuita. A troca mais significativa é a memória. A aba do navegador tem acesso à RAM do dispositivo, mas uma única aba travando porque uma imagem excedeu a memória disponível é uma experiência ruim. Limitamos arquivos individuais a 100 MB e lotes a 200 arquivos para permanecer dentro de limites seguros.

Também sacrificamos recursos do lado do servidor como armazenamento persistente, entrega de e-mail e análises. Não há banco de dados de imagens comprimidas, nenhum boletim informativo, nenhum registro de quais formatos os usuários preferem. Isso é filosoficamente consistente com nossa postura de privacidade, mas significa que não podemos oferecer recursos como "compressões recentes" ou "configurações salvas entre sessões".

O que vem a seguir

O navegador está se tornando um ambiente de execução legítimo para aplicações sensíveis a desempenho. À medida que o WebAssembly ganha coleta de lixo, threading e suporte SIMD, mais partes da pilha de aplicativos podem se mover para o lado do cliente. Estamos explorando WebGPU para processamento de pixels ainda mais rápido e a API File System Access para integração perfeita de pastas.

Por enquanto, o compressor está ativo e processando milhares de imagens por dia — todas permanecendo exatamente onde deveriam estar.