← Todos os posts

Como verificar que uma ferramenta web nunca envia seus arquivos (guia com DevTools)

2026-05-30

Resposta curta: abra o DevTools do navegador, vá na aba Network (Rede), limpe e então use a ferramenta com um arquivo. Se o arquivo nunca sai do seu navegador, você vai ver o código da ferramenta baixar — mas não vai ver os bytes do seu arquivo subir. Aqui vai a versão de 60 segundos, mais como ler o que você vê.

Por que "não guardamos seus arquivos" não basta

A maioria das ferramentas "gratuitas" online envia seu arquivo para um servidor, processa lá e devolve o resultado. A política de privacidade pode prometer apagá-lo depois — mas é uma promessa que você não consegue checar. "Não guardamos seus arquivos" ainda significa que seu arquivo foi transmitido e ficou, descriptografado, na máquina de outra pessoa. Uma garantia que você não pode verificar não é privacidade; é marketing.

A boa notícia: os navegadores modernos conseguem fazer o trabalho de verdade sozinhos — processamento de imagem, renderização de PDF, codificação de vídeo via WebAssembly, e até redes neurais via WebGPU. Quando uma ferramenta roda localmente, seu arquivo é lido na memória da aba, processado e devolvido como download. Ele nunca toca a rede. E, diferente de uma promessa, você mesmo pode confirmar isso em menos de um minuto.

A checagem de 60 segundos (aba Network)

  1. Abra a ferramenta numa aba nova (por exemplo, Compressor de imagem ou Imagem para texto).
  2. Abra o DevTools — aperte F12, ou clique com o botão direito → Inspecionar. (Cmd+Opt+I no Mac, Ctrl+Shift+I no Windows e Linux.)
  3. Clique na aba Network (Rede).
  4. Clique no ícone de limpar (🚫) para apagar as requisições, e marque Preserve log (Preservar registro) para nada sumir.
  5. Agora solte seu arquivo na ferramenta e execute.
  6. Olhe a lista de requisições e ordene por Size (Tamanho).

O que você procura: uma requisição que envia seu arquivo é um POST (ou PUT) com um corpo de requisição com mais ou menos o tamanho do seu arquivo. Envie uma foto de 5 MB e você veria um payload de ~5 MB saindo para fora. Se as únicas transferências grandes são o próprio código da ferramenta e os arquivos .wasm entrando para dentro — e param depois da primeira execução porque estão em cache —, seu arquivo ficou onde estava.

Como distinguir um envio do tráfego normal

Nem toda requisição é um alerta. Isto é normal até numa ferramenta 100% local:

  • Carregamento de código e recursos — bundles de JavaScript, binários .wasm (FFmpeg, Tesseract e cia), fontes, a própria página. São downloads: a resposta tem tamanho, o corpo da requisição está vazio, e ficam em cache depois da primeira visita.
  • Analytics e anúncios — pings pequenos para o Google Analytics ou AdSense. Minúsculos, e nunca contêm seu arquivo (não podem — seu arquivo não está em nenhuma variável que eles alcancem).

Isto sim é um alerta:

  • Um POST/PUT cujo payload tem mais ou menos o tamanho do seu arquivo. Abra a aba Payload/Request dessa requisição e você vê literalmente os bytes, ou um formulário multipart carregando o nome do seu arquivo.
  • Um envio para um domínio de armazenamento inesperado (um bucket S3, algum CDN) no exato momento em que você clica em "processar".

Regra de bolso: downloads entrando, sem envios grandes saindo = processamento local.

A opção nuclear: tire da tomada

Se você prefere não ler registros de requisição, há um teste mais bruto que qualquer um faz:

  1. Carregue a página da ferramenta uma vez para baixar o código.
  2. Ligue o modo avião / desligue o Wi-Fi — ou no DevTools coloque o dropdown de Network throttling em Offline.
  3. Execute a ferramenta.

Se ainda funciona offline, fisicamente não dá para estar enviando seu arquivo: não há conexão por onde enviar. (Algumas ferramentas baixam um motor grande sob demanda — algumas de vídeo puxam o FFmpeg na primeira vez. Deixe esse download terminar, depois desconecte e processe.)

Então por que tantas ferramentas enviam?

Honestamente, porque o lado servidor é mais fácil de monetizar. Enviar permite a uma empresa esconder recursos atrás de uma assinatura, registrar uso e — nos piores casos — guardar seus arquivos para treinar modelos. O processamento local exige mais engenharia: compilar bibliotecas C para WebAssembly, encaixá-las no orçamento de memória do navegador, abrir mão dessa alavanca. A troca vale por um motivo — seus arquivos não vão a lugar nenhum, e você não precisa acreditar em mim. Você pode olhar a aba Network.

É essa a ideia inteira por trás do ToolKoala: toda ferramenta roda no seu navegador. Abra o DevTools em qualquer uma e confira você mesmo.

Perguntas frequentes

"Sem envio" significa que a ferramenta funciona offline? Depois do primeiro carregamento, geralmente sim. O código fica em cache, então a maioria continua funcionando sem conexão. Algumas que baixam um motor grande sob demanda (algumas de vídeo) precisam desse download primeiro.

Uma ferramenta poderia enviar meu arquivo escondido por WebSockets ou em segundo plano? A aba Network também mostra o tráfego de WebSocket e de fetch/XHR em segundo plano, payload incluído. Se os bytes do seu arquivo saem, eles aparecem ali. É esse o ponto: um envio não tem onde se esconder da aba Network.

Analytics ou anúncios são um problema de privacidade? Eles veem sinais padrão de visita — localização aproximada, tipo de dispositivo —, não seu arquivo. Seu arquivo nunca entra numa variável que um script de anúncio alcance, e se você bloqueá-los as ferramentas continuam funcionando.

Isto é específico do ToolKoala? Não. Essa checagem serve para qualquer ferramenta web. Faça em todo "conversor online grátis" antes de confiar um arquivo sensível a um deles.

— Milo 🐨