Envie um arquivo para um conversor baseado em servidor e três coisas acontecem. Seu arquivo viaja pela rede até um endereço IP que você não controla. Um processo nesse servidor o decodifica. Depois, dependendo da política de retenção do site, o arquivo permanece em disco por minutos ou para sempre.
Faça a mesma coisa em uma aba do navegador e o arquivo nunca sai da RAM da sua máquina. O decodificador executa dentro de um sandbox WebAssembly imposto pelo motor do navegador. A rede nunca é tocada.
Isso não é uma diferença de política. É uma diferença arquitetural. Um conversor baseado em servidor pode prometer excluir seus arquivos; um baseado em navegador não pode vazá-los porque nunca os recebe.
A Arquitetura
Quatro camadas fazem a conversão no lado do cliente funcionar:
Camada 1: Acesso a Arquivos
Quando você solta um arquivo em uma aba do navegador, o DragEvent ou <input type="file"> fornece ao JavaScript um objeto File. Um File não é o conteúdo do arquivo. É uma referência: um nome, um tamanho, um tipo MIME e um método (file.arrayBuffer()) que lê bytes do disco para a memória sob demanda.
Até que esse método seja chamado, zero bytes foram movidos. O arquivo permanece no seu sistema de arquivos. O seletor de arquivos do navegador é um diálogo no nível do sistema operacional; a página web vê apenas o objeto File que o usuário selecionou explicitamente.
Camada 2: Detecção de Formato
Os primeiros bytes de qualquer arquivo identificam seu formato de forma confiável. Um JPEG começa com FF D8 FF. Um PNG começa com 89 50 4E 47. Um arquivo HEIC contém um box ftyp com uma marca heic ou heif no deslocamento 8.
Ler o cabeçalho de um arquivo (os primeiros 32 bytes, tipicamente) é suficiente para confirmar o que ele realmente é, independentemente da extensão. Esta verificação executa antes que qualquer decodificador toque nos dados de pixel. Se o cabeçalho não corresponder, o arquivo é rejeitado imediatamente. Sem CPU desperdiçada, sem mensagens de erro confusas no meio de uma decodificação.
Camada 3: Decodificação
Bytes brutos se tornam pixels através de um decodificador. Qual decodificador depende do formato:
- JPEG, PNG, WebP, BMP: o navegador possui decodificadores nativos para estes.
createImageBitmap()entrega os bytes comprimidos ao codec da plataforma (Windows Imaging Component no Windows, Core Graphics no macOS, Skia no Linux/ChromeOS) e retorna dados de pixel brutos. Este caminho é rápido, acelerado por hardware onde o sistema operacional suporta, e não requer código adicional. - HEIC: nenhum navegador exceto o Safari possui um decodificador HEIC nativo. Nosso conversor inclui o libheif, uma biblioteca C, compilada para WebAssembly. O binário
.wasm(~1,2 MB comprimido) é baixado uma vez e armazenado em cache. Ele decodifica arquivos HEIF/HEIC para pixels RGB brutos inteiramente dentro do sandbox WASM. - PDF: PDF.js (o renderizador de PDF da Mozilla) renderiza cada página para um canvas na resolução solicitada. Sem renderização no servidor. O PDF nunca sai do navegador.
Todo decodificador lê da memória e escreve na memória. Nenhum abre sockets. O sandbox WASM em particular não pode fazer requisições de rede: o navegador não expõe APIs de rede para módulos WebAssembly. Mesmo que o código C chamasse socket(), o sandbox o interceptaria.
Camada 4: Codificação
Pixels brutos vão para o contexto 2D de um elemento <canvas>. canvas.toBlob() ou canvas.toDataURL() chama o codificador embutido do navegador para saída JPG, PNG ou WebP. O codificador é código nativo da plataforma: o mesmo caminho de código que seu sistema operacional usa para salvar capturas de tela.
A saída é um Blob, um buffer de bytes em memória. Ele é entregue a um link de download ou empacotado em um arquivo ZIP construído em JavaScript. Em nenhum momento qualquer byte toca um socket de rede.
O Que o Navegador Impõe
Páginas web executam dentro de um sandbox que o navegador mantém no nível do motor. Isso não é um acordo educado. É imposto por isolamento de processos:
Processo renderizador: o motor JavaScript, DOM e runtime WASM vivem em um processo isolado sem acesso direto ao sistema de arquivos ou à rede. Ele se comunica com o mundo externo através de IPC para o processo do navegador.
Isolamento de sites: navegadores modernos colocam cada origem em seu próprio processo renderizador. Seus arquivos em file-convert-factory.org são invisíveis para JavaScript executando em qualquer outro domínio.
Sandbox WASM: módulos WebAssembly veem um buffer de memória linear plano e nada mais. Sem APIs de sistema de arquivos, sem fetch a menos que explicitamente importado do JavaScript, sem acesso ao DOM ou outras APIs do navegador. O pior que um módulo WASM comprometido poderia fazer é corromper sua própria memória e travar a aba.
Um conversor baseado em servidor executa como um processo privilegiado no sistema operacional do servidor. Ele pode ler do disco, gravar no disco, abrir conexões de rede e gerar processos filhos. O modelo de segurança depende da competência e das intenções do operador do servidor. O sandbox do navegador depende apenas da correção do motor do navegador, e os sandboxes de navegador estão entre as barreiras de segurança mais rigorosamente auditadas em software.
O Que os Conversores Baseados em Servidor Prometem (e Não Prometem)
Conversores baseados em servidor não são inerentemente maliciosos. Muitos são operados por equipes bem-intencionadas. O problema é estrutural:
- O passo de upload é uma cópia. Seu arquivo agora existe em dois lugares. Você controla uma cópia. Outra pessoa controla a outra.
- A exclusão é uma promessa. "Excluímos arquivos após 24 horas" significa confiar na linha de log, no cron job, no sistema de backup e em cada funcionário com acesso ao servidor. Nada disso é verificável de fora.
- Metadados viajam com o arquivo. Os dados EXIF da sua foto (coordenadas GPS, número de série da câmera, timestamp) fazem parte dos bytes do arquivo. Se o arquivo é enviado, os metadados são enviados. Nosso guia de privacidade EXIF cobre exatamente o que está lá e como removê-lo. A versão resumida: todo conversor neste site remove metadados porque decodifica pixels e os recodifica, descartando tudo que não é dado de imagem.
- HTTPS protege o canal, não o destino. TLS criptografa o upload em trânsito. Não faz nada sobre o que acontece com o arquivo depois que ele chega.
A garantia de privacidade de um conversor baseado em navegador é mais restrita, mas mais forte. Ela diz: seus arquivos não saem do seu dispositivo porque não há caminho de código para que isso aconteça. Isso é verificável. Abra a aba Network no DevTools enquanto converte um arquivo. Você verá o binário WASM carregar uma vez e depois nada. Zero bytes enviados. Sem requisições para /api/convert. Sem tráfego WebSocket. A conversão acontece inteiramente dentro do processo renderizador.
Verificando Você Mesmo
Você não precisa acreditar na palavra de ninguém. Abra o Chrome DevTools (F12), mude para a aba Network e converta um arquivo em qualquer página de ferramenta. A única atividade de rede que você verá:
- O HTML, CSS e JavaScript da página: carregados uma vez na primeira visita.
- O binário WASM (para conversores HEIC): carregado uma vez, armazenado em cache depois.
- Requisições de analytics (se você não as bloqueou).
Nenhum dado de arquivo sai do navegador. O Content-Length de cada requisição é medido em kilobytes, não megabytes. Isso é verificável independentemente por qualquer pessoa que saiba abrir o DevTools.
O mesmo não pode ser dito sobre um serviço baseado em servidor. Você envia o arquivo, recebe um resultado e confia que o servidor o excluiu.
Ferramentas Relacionadas
Todo conversor neste site segue esta arquitetura. O pipeline (soltar, validar, decodificar, codificar, baixar) executa de forma idêntica em todas as 23 ferramentas:
- HEIC para JPG · HEIC para PNG · HEIC para WebP
- JPG para PNG · JPG para WebP · JPG para ICO
- PNG para JPG · PNG para WebP · PNG para ICO
- WebP para JPG · WebP para PNG · WebP para ICO
- BMP para JPG · BMP para PNG · BMP para WebP · BMP para ICO
- PDF para JPG · PDF para PNG · PDF para WebP
- Imagem para Texto (OCR): mesma arquitetura do lado do cliente, executa Tesseract em WASM
Para os detalhes técnicos do sandbox WASM, veja nosso explicador de WebAssembly. Para uma análise mais profunda dos metadados que suas fotos carregam, o guia de privacidade EXIF explica como lê-los e removê-los byte por byte.
