Como funciona a conversão de arquivos no navegador

A maioria dos conversores online envia seu arquivo para um servidor. O nosso não pode: todas as ferramentas deste site fazem a conversão dentro do seu navegador, com JavaScript e WebAssembly. Esta página explica exatamente o que isso significa, como verificar por conta própria e, igualmente importante, o que isso torna impossível.

Por que “nenhum upload” é uma diferença de arquitetura real

Um conversor baseado em servidor é um cliente fino: o navegador envia o arquivo, o servidor faz o trabalho e o resultado volta. Esse desenho tem vantagens (o servidor pode executar qualquer biblioteca, por maior que seja) e um custo estrutural: o arquivo precisa existir numa infraestrutura que você não controla, pelo menos por um tempo. Políticas de retenção, logs e backups ficam todos fora do seu campo de visão.

Este site foi construído ao contrário. Não existe endpoint de upload. A página carrega uma biblioteca JavaScript que decodifica o arquivo na memória, transforma-o e devolve o resultado como um download local. Se a rede fosse desligada depois que a página carregasse, a ferramenta continuaria funcionando.

O fluxo, passo a passo

1. Ler. O arquivo é lido com as APIs do navegador FileReader / File.arrayBuffer(). Ele se torna bytes na memória da página, nunca uma requisição.
2. Decodificar. Esses bytes são decodificados pelos codecs de imagem do próprio navegador (via <img> ou createImageBitmap) ou por uma biblioteca WebAssembly enviada para formatos que o navegador não suporta nativamente, como libheif para HEIC ou pdf.js para páginas PDF.
3. Transformar. Os dados decodificados são desenhados num <canvas> ou manipulados na memória: redimensionar, cortar, girar, recolorir, recodificar.
4. Codificar. O canvas é gravado de volta num formato binário com canvas.toBlob(), ou um documento é reconstruído com uma biblioteca JavaScript pura, como pdf-lib.
5. Entregar. O resultado vira um Blob e uma URL de objeto, que a página dispara como download. Nada é transmitido.

Como verificar você mesmo

Não acredite apenas no que esta página diz. Abra as ferramentas de desenvolvedor do seu navegador, vá até o painel Rede e converta um arquivo. Depois veja o que aconteceu:

• Você verá requisições para a página, a folha de estilos, as bibliotecas JavaScript e a tag de analytics, todas por URL.
• Você não verá nenhuma requisição cujo corpo seja o seu arquivo. Não há nenhum POST com alguns megabytes de payload.
• No mesmo painel, marque “Offline” depois que a página carregar e converta de novo. Continua funcionando, o que não aconteceria se houvesse um servidor envolvido.

Se quiser ir mais longe, observe a aba Memória ou Desempenho ao converter um PDF grande e você verá a alocação acontecer no próprio processo da página.

O que um navegador faz bem

• Decodificar e codificar imagens. JPEG, PNG, WebP, GIF e AVIF são decodificados nativamente, e o canvas consegue codificar a maioria deles de volta.
• Transformações de pixels. Redimensionar, cortar, girar, compor, ajustar cor: tudo assistido por hardware pela API de canvas.
• Renderização de páginas PDF. O pdf.js é um renderizador de PDF completo escrito em JavaScript, então uma página pode virar um canvas em qualquer resolução.
• Montagem de documentos. O pdf-lib consegue criar e modificar estruturas PDF (juntar, dividir, reordenar, adicionar sobreposições) sem renderizar nada.
• Processamento de texto. JSON, CSV, Markdown, Base64 e formatos semelhantes não custam nada em JavaScript.

O que um navegador não consegue fazer

Ser honesto sobre isso importa mais do que listar capacidades, porque esses limites são a razão de algumas conversões se comportarem aqui de forma diferente do que numa ferramenta baseada em servidor.

• Recomprimir no lugar as imagens embutidas de um PDF. Um otimizador de servidor consegue decodificar cada imagem de um PDF, recodificá-la de forma mais eficiente e reconstruir o arquivo com a camada de texto intacta. Num navegador isso não é prático, e é por isso que nossa compressão de PDF oferece duas opções: reempacotar o arquivo (o texto permanece, a economia é modesta) ou rasterizar as páginas (economia grande, o texto vira imagem).
• Codificar AVIF em todos os navegadores. Criar um AVIF exige o codificador do navegador, que hoje só existe em navegadores baseados em Chromium. No Firefox e no Safari um conversor precisa dizer isso em vez de produzir outra coisa em silêncio.
• Decodificar TIFF, ou HEIC sem ajuda. Os navegadores não trazem esses codecs, então é preciso baixar um decodificador WebAssembly: cerca de 600 KB para o de HEIC, buscado uma vez e depois armazenado em cache.
• Codificar GIF. Os navegadores decodificam GIF mas não codificam, então uma saída GIF exige um codificador em JavaScript.
• OCR sem modelo. Ler texto de um scan exige um modelo de reconhecimento treinado de vários megabytes; é outro tipo de recurso, não uma conversão de formato.
• Lidar com arquivos de qualquer tamanho. Tudo vive na memória da página, então o teto prático é a RAM do seu dispositivo e não uma cota de servidor. Algumas centenas de megabytes funcionam numa máquina moderna; vários gigabytes, não.

Por que publicar os limites

Uma ferramenta que afirma não ter limites normalmente está escondendo algo. Publicá-los permite que você decida se vale a pena fazer uma dada conversão aqui, e faz com que os números das páginas de ferramentas (a resolução, a qualidade, o tamanho do arquivo) possam ser conferidos com o que a implementação realmente faz.

Se você escreve sobre ferramentas que rodam no navegador e quer uma citação, esta página serve exatamente para isso. Nenhuma permissão necessária.

← ← Voltar para as ferramentas