Como a AtlasDocs roda mais de 130 ferramentas sem enviar nada ao servidor

Este artigo foi publicado primeiro no blog da AtlasDocs: https://atlasdocs.io/blog/como-o-atlasdocs-processa-arquivos-no-navegador

Quando alguém junta dois PDFs, extrai o áudio de um vídeo ou lê o texto de uma foto no AtlasDocs, o arquivo não viaja para lugar nenhum. O navegador baixa o programa que faz o trabalho, e o trabalho acontece na memória da máquina de quem usa. O resultado nasce ali e é salvo direto no dispositivo. Não existe upload, não existe fila em servidor, e não existe uma cópia do documento guardada em algum lugar esperando ser apagada.

A página de privacidade diz isso em uma frase. Este texto explica como é possível, e onde estão os limites.

WebAssembly é o que torna isso viável

A base é o WebAssembly, que permite rodar dentro do navegador programas escritos originalmente para computador. É assim que motores conhecidos passaram a funcionar numa aba:

• 7-Zip para arquivos compactados (via 7z-wasm)
• FFmpeg para vídeo e áudio (via ffmpeg.wasm)
• Tesseract para reconhecer texto em imagens (via tesseract.js)
• SQLite para bancos de dados (via sql.js)
• Leitura de RAR (via node-unrar-js)
• MediaInfo para inspecionar mídia (via mediainfo.js)

Para PDF, duas bibliotecas de código aberto escritas para o navegador: pdf-lib, que edita o documento, e pdf.js, mantida pela Mozilla, que desenha as páginas na tela.

O motor pesado só carrega quando alguém pede

Reconhecer texto numa foto exige um motor grande, mais o modelo de idioma. Se ele viesse junto com a página, o site ficaria lento para todo mundo, inclusive para quem só quer girar um PDF.

Por isso cada ferramenta carrega o próprio motor sob demanda, no primeiro uso. No código isso é um import() dinâmico na camada de infraestrutura, do tipo:

const { optimizeForSocial } = await import("@/infrastructure/image");

A página inicial pesa o mesmo com ou sem as ferramentas pesadas, e um gate de peso no pipeline de testes impede que uma versão suba se a home ou uma ferramenta ficar mais pesada que o limite. É também por isso que o primeiro uso de uma ferramenta de vídeo demora alguns segundos a mais: é o download do motor, uma única vez, que o navegador guarda em cache.

Os motores ficam hospedados no próprio site, com cópias de reserva em CDNs públicas caso a primeira falhe. Se você abriu um RAR lá, o motor veio do servidor; o seu arquivo, não.

FFmpeg inteiro dentro da aba

Extrair áudio, juntar vídeos, trocar formato, colocar marca d'água: tudo usa o FFmpeg, o mesmo programa de estúdios e serviços de streaming. A versão para navegador roda num Web Worker, então a interface continua respondendo enquanto o vídeo é processado.

O limite é a memória do dispositivo. Um vídeo de várias centenas de megabytes pode não caber num celular simples. Quando não cabe, a conversão falha e a ferramenta mostra uma mensagem de erro. Nada é enviado para fora para tentar de novo.

RAR: ler sim, criar não

RAR é formato fechado. A licença permite ler e extrair, mas não criar arquivos RAR fora do programa oficial. Por isso a plataforma AtlasDocs abre, extrai e converte RAR para ZIP ou 7z, mas não gera RAR. Foi uma decisão de respeitar a licença, não uma limitação técnica.

As duas exceções, ditas na própria ferramenta

Duas ferramentas enviam o arquivo ao servidor: converter documentos do Word, Excel e PowerPoint para PDF, e visualizar esses mesmos documentos. O motivo é técnico. Não existe hoje um programa para navegador que abra arquivos do Office com fidelidade; o que faz isso bem é o LibreOffice, que precisa de um servidor. Nesses dois casos o arquivo é convertido e descartado em seguida, e a ferramenta mostra um aviso na tela antes do envio. As outras mais de 130, continuam no dispositivo.

Há mais dois pontos de contato com o servidor, e nenhum vê arquivos. O assistente de ajuda envia a pergunta digitada para um modelo de linguagem, e só ela. E o contador de visitas registra apenas o caminho da página: sem cookie, sem IP guardado, sem identificação de pessoa.

Como conferir por conta própria

1. Abra qualquer ferramenta da AtlasDocs no computador e pressione F12.
2. Vá na aba Network e deixe a lista de requisições aberta.
3. Envie um arquivo e execute a operação até baixar o resultado.
4. Olhe a lista: você verá o download do motor e das páginas do site, e nenhum POST com o conteúdo do seu arquivo. As duas exceções mostram o envio, como o aviso na tela diz.

Como o código é mantido

• TypeScript no modo estrito, cerca de 76 mil linhas, Next.js 16 e React 19.
• Cada regra de negócio vive em um módulo separado da interface (capabilities e pipelines), o que permite reaproveitar a mesma conversão em ferramentas diferentes.
• A cada versão rodam 737 testes unitários e 176 testes em navegador real, que abrem as páginas, enviam arquivos de verdade e conferem o resultado.
• Lighthouse no celular entre 94 e 97, medido em produção a cada release.
• Interface em português, inglês e espanhol.

O que eu faria diferente hoje

O gate de peso e a medição de Lighthouse por release entraram tarde, depois que a página inicial já tinha chegado a 68 pontos no celular. Ter isso desde o primeiro commit teria evitado um dia inteiro de otimização. Se você está começando algo parecido, coloque o orçamento de peso antes da segunda ferramenta.

Se tiver alguma dúvida sobre como uma conversão específica funciona, pergunte nos comentários. A plataforma AtlasDocs está em https://atlasdocs.io.