As ferramentas de arquivos baseadas no navegador fazem o trabalho dentro da página em vez de em um servidor. Seu arquivo é lido do disco pela File API, processado por um mecanismo WebAssembly como o qpdf ou o FFmpeg rodando na aba, e escrito de volta como um download. Não existe etapa de upload, então nada é enviado.
A arquitetura tem três partes. As APIs File e Blob movem bytes entre o seu disco e a página sem uma ida e volta pela rede. O WebAssembly roda mecanismos que originalmente foram escritos para o desktop, e é por isso que os resultados batem com uma ferramenta de desktop em vez de uma aproximação web simplificada. O Canvas, os Web Workers e o MediaRecorder cobrem os trabalhos que precisam de desenho, processamento em segundo plano ou uma câmera. A troca é que a primeira execução baixa o mecanismo, e tudo tem de caber na memória de uma única aba.
A maioria das pessoas encontra essa ideia em uma linha de privacidade em uma página de ferramenta: os arquivos nunca saem do seu dispositivo. Essa frase é verdadeira ou não é, e quem decide é a arquitetura e não a intenção. Este guia explica o que um navegador realmente consegue rodar hoje, por que a etapa de upload desaparece quando você constrói desse jeito, e os custos que vêm com isso.
Compressor de imagem
Um exemplo concreto. O Canvas e o OxiPNG rodam na aba, os tamanhos antes e depois são mostrados lado a lado, e o arquivo nunca é enviado.
Duas arquiteturas: a ida e volta ao servidor e a aba local
A maioria dos conversores online segue o mesmo formato. Seu navegador envia o arquivo a um servidor com um upload HTTP, o servidor roda uma ferramenta como ImageMagick ou um FFmpeg headless, e um link de download volta. O trabalho é real e muitas vezes rápido, mas o arquivo precisa sair da sua máquina para que isso aconteça, e ele permanece nessa máquina pelo tempo que o operador o guardar.
Uma ferramenta baseada no navegador mantém as mesmas etapas e descarta o servidor. Ler o arquivo, executar o mecanismo e escrever o resultado acontecem todos na aba. Isso não é uma pequena variação do modelo de upload. Elimina toda uma classe de problemas, porque não há transferência para interceptar, nem fila para esperar, nem janela de retenção para ler.
| Etapa | Ferramenta baseada em servidor | Ferramenta baseada no navegador |
|---|---|---|
| Ler o arquivo | Copiado para o armazenamento deles | Lido pela File API, permanece local |
| Processamento | A CPU deles, geralmente na fila | Sua CPU, dentro da aba |
| Resultado | Um link de download que expira | Um download por Blob, pronto imediatamente |
| Quem pode ler o arquivo | Qualquer um com acesso ao armazenamento deles | Somente você |
O que o navegador realmente roda
Um pequeno passeio pela pilha, porque essas capacidades são o que torna possível a promessa de privacidade, e não uma camada de marketing colada por cima.
O WebAssembly traz mecanismos de desktop para a aba
O WebAssembly é um formato binário compacto que roda a velocidade próxima da nativa dentro de uma máquina virtual em sandbox. Mecanismos escritos em C, C++ ou Rust são compilados para ele e enviados como arquivos comuns: qpdf para criptografia de PDF, FFmpeg para vídeo e áudio, Tesseract para reconhecimento óptico de caracteres, pdf-lib para construir e editar PDFs, e OxiPNG para otimização de PNG sem perdas. O PDF.js cuida da renderização e extração de texto de PDFs. Como esses são os mesmos mecanismos usados no desktop, a saída não é uma aproximação web: um vídeo codificado pela build do FFmpeg na sua aba é a saída do FFmpeg.
O Canvas e o pipeline de imagem
As imagens são a única categoria que não precisa de WebAssembly. A Canvas API expõe a mesma superfície de desenho que um editor de imagens nativo usa. createImageBitmap decodifica um arquivo, um canvas guarda os pixels, e toBlob codifica o resultado de volta em PNG, JPEG, WebP ou AVIF. Recortar, redimensionar, aplicar marca d'água e converter formatos são todas operações de pixel nessa superfície. O Compressor de imagem combina-o com OxiPNG para saída PNG, que recomprime o arquivo sem perdas em vez de jogar qualidade fora.
Os Web Workers mantêm a interface viva
Trabalho pesado na thread principal congela a página, então os trabalhos longos rodam em um Web Worker, uma thread em segundo plano sem acesso ao DOM. As ferramentas de vídeo entregam o trabalho ao FFmpeg dentro de um worker e recebem linhas de log e eventos de progresso de volta, e é por isso que a barra de progresso continua se movendo enquanto o codificador está ocupado. O Tesseract segue o mesmo padrão. Notavelmente, a configuração de OCR aqui usa uma build de mecanismo single-thread, então ela não precisa dos cabeçalhos SharedArrayBuffer que muitas ferramentas WebAssembly exigem do servidor.
File e Blob movem os bytes
A File API é o que substitui o upload. Quando você solta um arquivo na página, o JavaScript recebe um objeto File, e file.arrayBuffer() lê seus bytes para a memória sob demanda. O resultado é um Blob, que pode virar uma URL local temporária ou ser entregue direto a um download. Os bytes viajam do disco para a memória e de volta, e não há nenhum caminho de código nesse ciclo que fale com uma rede. É também por isso que uma ferramenta de navegador não tem limite de tamanho de upload imposto por um servidor, apenas o limite de memória do dispositivo.
Por que o processamento local significa que nada é enviado
A alegação é fácil de afirmar e fácil de verificar. Enviar é uma requisição de rede que carrega o seu arquivo, e uma ferramenta de navegador nunca faz uma, porque não há nada do outro lado que precise dela. As únicas requisições que uma página como esta faz são para o próprio código e recursos: o HTML, a folha de estilo, o mecanismo no primeiro uso e a fonte.
Você não precisa acreditar nisso pela fé. Abra as ferramentas de desenvolvedor do navegador, mude para o painel de rede, limpe-o, depois processe um arquivo e observe. As requisições que aparecem carregam código e recursos. Nenhuma delas carrega o seu documento, e se você desconectar da rede depois que o mecanismo foi carregado, o processamento continua funcionando. Há um guia mais longo, passo a passo, sobre verificar se uma ferramenta envia seu arquivo se você quiser o procedimento completo.
| Requisição que você verá | O que ela carrega |
|---|---|
| A página, seu CSS e seu JavaScript | Código do site, não o seu arquivo |
| O mecanismo, no primeiro uso | Uma ferramenta compilada, armazenada em cache depois |
| Fontes web | Uma fonte |
| Script de analytics | Uma visualização de página, não os bytes do arquivo |
A última linha importa porque é a fonte usual de falsos alarmes. O analytics carrega na página e relata que uma página foi visualizada, não o conteúdo do seu documento. Este próprio site carrega o Google Tag Manager, e é por isso que o painel de rede mostra um script do Google. Essa requisição relata uma visualização de página, e não é uma transferência de arquivo.
O que você paga por isso
O processamento local não é gratuito, e a versão honesta do argumento merece ser dita claramente. Três custos aparecem, e um quarto ponto explica onde o navegador para.
- A primeira execução baixa. Cada mecanismo é buscado uma vez: cerca de 30 MB para o núcleo FFmpeg por trás das ferramentas de vídeo e áudio, cerca de 6.7 MB para o mecanismo de OCR e os dados de inglês, cerca de 1.3 MB para o mecanismo de PDF, e cerca de 1.4 MB para o worker do PDF.js usado nas prévias de página. Nada disso é o seu arquivo, e tudo isso fica em cache, mas uma partida a frio em uma conexão lenta é uma partida lenta.
- A memória é o teto. Tudo o que o mecanismo lê e escreve vive em uma única aba. Uma ferramenta de desktop faz streaming de um arquivo grande do disco, enquanto uma aba do navegador o mantém, então um vídeo ou PDF enorme pode esgotar a memória antes de terminar. Algumas ferramentas declaram um teto rígido por esse motivo, como o limite de 50 MB na ferramenta de desbloqueio de PDF.
- Um servidor pode ser mais rápido. A codificação de vídeo é limitada pela CPU, e uma máquina dedicada com mais núcleos e um cache mais quente supera uma aba de laptop. A build do navegador também recorre à codificação por software em vez de um codificador de hardware, então ela não obtém o ganho de velocidade de GPU que uma build nativa consegue usar.
- Alguns trabalhos ainda precisam de um servidor. A remoção de fundo, o apagamento de objetos e o melhoramento generativo de imagens dependem de modelos grandes que nenhum orçamento razoável de download cobre. Esses três são tratados pelo Cloud AI e de fato enviam a imagem. Todo o resto do site é local.
Para um documento de alguns megabytes ou um clipe de um minuto, nenhum desses custos é sentido, e a troca compra privacidade e a ausência de cotas. Para uma gravação 4K de duas horas, uma ferramenta de desktop ou um trabalho em servidor é a melhor escolha, e a resposta honesta é dizer isso.
O mesmo padrão em todo o conjunto de ferramentas
O página inicial agrupa as ferramentas em cinco seções, e a arquitetura é a mesma em cada uma. O trabalho de PDF roda em qpdf, pdf-lib e PDF.js. Por exemplo Combinar PDF combina arquivos com pdf-lib, enquanto PDF para texto extrai texto com o PDF.js e recorre ao Tesseract apenas para páginas digitalizadas. O trabalho de imagem roda em Canvas e OxiPNG. Vídeo e áudio rodam em FFmpeg, com Compressor de vídeo e as ferramentas de áudio compartilhando um único mecanismo. O OCR roda no Tesseract. As três ferramentas Cloud AI são a exceção, e o site as rotula como tal em vez de borrar a linha.
A conclusão prática é que você pode raciocinar sobre qualquer ferramenta da mesma forma. Se ela nomeia um mecanismo real e o roda na aba, o arquivo fica no lugar. Se ela precisa de um modelo maior do que um navegador consegue baixar, ela dirá que faz upload, e deveria dizê-lo na página e não em uma nota de rodapé.
