A resposta curta
O RoundCut usa uma arquitetura híbrida: a maioria das ferramentas roda inteiramente no seu navegador, com zero envio, e um punhado envia uma única requisição de rede através da nossa própria infraestrutura quando o navegador não consegue igualar a qualidade, sempre com um fallback invisível no lado do cliente. Dizemos em qual caminho você está, em cada ferramenta e nesta página.
A tabela abaixo é representativa, não exaustiva (ferramentas novas chegam com frequência). Ela mostra um exemplo de cada tipo de caminho:
| Ferramenta de exemplo | Onde o trabalho acontece |
|---|---|
| Recorte em Círculo (só navegador) | 100% no seu navegador, Canvas API. Sem envio, funciona offline. |
| Pré-visualização da compressão (só navegador) | 100% no seu navegador, canvas.toBlob. Sem envio. O controle deslizante fica instantâneo. |
| Download final da compressão (toca o servidor) | Uma ida e volta ao nosso serviço em api.roundcut.com.br (Fastify + sharp + libvips em um VPS na Alemanha), com fallback no navegador. |
| Remover Fundo (toca o servidor) | Uma ida e volta a um Cloudflare Worker que roda o BiRefNet nas GPUs de borda da Cloudflare, com fallback em WebAssembly no seu navegador quando a nuvem está inacessível. |
Recorte, redimensionamento, conversão de formato (exceto a codificação AVIF) e a pré-visualização da compressão rodam todos por completo no seu navegador. A remoção de fundo, o download da compressão, a ampliação com IA, a codificação AVIF e o PDF com várias imagens enviam, cada um, uma única requisição e recorrem ao navegador quando a nuvem está inacessível.
Você pode verificar as alegações sobre o lado do cliente em cerca de 30 segundos: abra o DevTools → Network, limpe o registro, depois use uma ferramenta só de navegador como o Recorte em Círculo ou o controle de pré-visualização da compressão, você verá zero requisições levando os bytes da sua imagem para fora da página. Para as ferramentas que tocam o servidor você verá exatamente um envio por operação, para endpoints identificados.
Por que híbrida
A maioria das ferramentas de imagem online fica em um extremo: enviar-tudo-para-um-servidor (você espera pelas idas e voltas e o operador guarda seu arquivo) ou tudo-no-navegador (você paga em qualidade e velocidade nas etapas de codificação/IA). Nenhum dos extremos vence em todo lugar.
Escolhemos o lado do cliente onde os navegadores já são excelentes, o elemento
<canvas> cuida do recorte, da rotação, do redimensionamento e da codificação de
pré-visualização com perda em JPG/WebP, e o lado do servidor onde o navegador ainda
perde de forma mensurável:
- Compressão de imagem, no download final. O
sharp+libvips 8.17no servidor produz arquivos 10 a 15% menores byte a byte do que os codificadores do navegador na mesma qualidade visual, e dá acesso ao ajuste de velocidade/croma do AVIF e à saída em JPEG XL que o navegador não expõe. O controle deslizante e a pré-visualização ainda rodam no seu navegador para que a iteração fique instantânea, só o toque em “Download” passa pelo nosso serviço. - Remoção de fundo com IA e ampliação com IA, no caminho padrão. Os modelos (BiRefNet para segmentação, super-resolução para ampliação) precisam de uma GPU de verdade para terminar em segundos. Os fallbacks no navegador funcionam, mas são mais lentos e produzem um resultado visivelmente mais bruto em cabelo, pelo e bordas finas.
- Codificação AVIF, na conversão. O codificador AVIF no navegador é lento em alguns dispositivos, então a saída AVIF envia uma requisição ao Worker de compressão, com a codificação no navegador na thread principal como fallback.
O custo que aceitamos por estar no servidor nesses caminhos é uma ida e volta por operação. O custo que evitamos por ficar no cliente em todo o resto é a taxa de ida e volta nas partes do fluxo que iteram mais rápido.
O pipeline, passo a passo
1. Você seleciona um arquivo
Pelo seletor de arquivos, por arrastar e soltar ou por colar, o navegador entrega ao
JavaScript um objeto File. O JavaScript lê os bytes usando FileReader ou
Blob.arrayBuffer(). Em nenhum momento deste passo o arquivo é enviado pela rede,
seja qual for a ferramenta que você esteja usando.
2. O navegador decodifica a imagem
Os navegadores modernos decodificam JPG, PNG, WebP, GIF e AVIF nativamente. Usamos o
createImageBitmap() para transformar os bytes brutos em um bitmap com que a GPU
pode trabalhar, fora da thread principal. Para HEIC em navegadores que não o
decodificam nativamente, recorremos a um decodificador WebAssembly que roda
localmente no seu navegador.
3. A ferramenta faz o que tem que fazer, é aqui que os caminhos divergem
- Ferramentas só de navegador (recorte, redimensionamento, conversão de formato para PNG/JPEG/WebP, a pré-visualização da compressão). Uma transformação de pixels no Canvas 2D ou um codec WebAssembly recodifica o bitmap localmente. O resultado fica pronto sem nenhum envio. O Cropper.js cuida do quadro interativo de recorte nas ferramentas de recorte, e o
canvas.toBlobcuida da recodificação da pré-visualização. Inteiramente no seu navegador. - Compressão, download. Quando você toca em “Download”, a imagem é enviada uma vez para
api.roundcut.com.br(um serviço Fastify rodando em um VPS na Alemanha operado pela Hostinger, Node 24 +sharp 0.34+libvips 8.17, as mesmas bibliotecas C que o Squoosh usa no caminho de servidor dele). Ela é recodificada com os mesmos parâmetros que você definiu na pré-visualização, e os bytes voltam em fluxo para o seu navegador. O serviço mantém um cache isolado por inquilino e endereçado por conteúdo (um hash dos bytes de entrada + parâmetros) limitado a 500 MB, para que baixar de novo a mesma imagem com as mesmas configurações reproduza os bytes em cache, o cache não é indexado por você, IP ou nome de arquivo. Se o serviço estiver inacessível, a ferramenta recorre ao blob de pré-visualização no navegador. - Remover Fundo, caminho padrão na nuvem. A imagem é enviada uma vez a um Cloudflare Worker, guardada temporariamente em um bucket R2 privado, processada pela transformação
cf.image.segmentda Cloudflare que roda o modelo BiRefNet nas GPUs de borda da Cloudflare, e o recorte volta em fluxo. O objeto R2 temporário é apagado em até uma hora por uma regra de ciclo de vida do R2, qualquer que seja o resultado. Uma foto típica termina em 1 a 3 segundos. Limites diários por IP e de envio de 5 MB mantêm o nível gratuito sustentável. - Outras ferramentas apoiadas na nuvem (ampliação com IA, codificação AVIF, PDF com várias imagens) seguem o mesmo formato: uma requisição a uma infraestrutura identificada (uma API de imagem na nuvem para super-resolução, o Worker de compressão para a codificação AVIF, o nosso serviço de VPS para o PDF com várias imagens), resultado de volta em fluxo, e um fallback transparente no navegador se essa requisição falhar.
- Fallback em WebAssembly. Se o caminho na nuvem relevante estiver inacessível (sua rede caiu, você está atrás de um firewall rígido, a cota diária esgotou ou o arquivo excede o limite da nuvem), a ferramenta passa de forma transparente para um modelo ou codec local rodando no seu navegador, por exemplo o modelo de remoção de fundo ISNet via ONNX Runtime Web com WebAssembly. A primeira execução baixa o modelo e é mais lenta, as execuções seguintes são mais rápidas. Sem nenhum envio nesses caminhos de fallback, você pode verificar no DevTools.
4. Você baixa o resultado
O bitmap de saída é codificado em um Blob, embrulhado em uma object URL e
oferecido à caixa de diálogo padrão de salvar arquivo do seu navegador. O arquivo
aparece no seu disco.
Como verificar você mesmo
Escolha o que preferir:
Método 1. Observe a aba Network
- Abra o RoundCut em uma aba nova e abra o DevTools → Network.
- Use uma ferramenta só de navegador, o Recorte em Círculo ou o controle de pré-visualização da compressão. Você verá requisições só de HTML/CSS/JS/fontes, mais os módulos WebAssembly relevantes no primeiro uso. Nenhuma requisição vai levar os bytes da sua imagem.
- Agora use uma ferramenta que toca o servidor, Compressão → Download ou Remover Fundo. Você verá exatamente um
POSTlevando sua imagem, e uma resposta voltando com o resultado. Passe o cursor sobre qualquer requisição para ver tamanho e tempo.
A coluna “Initiator” te diz qual script disparou cada requisição, e a coluna “Type” te diz o que foi enviado. Não escondemos nenhuma das duas.
Método 2. Use as ferramentas offline
- Carregue qualquer página de ferramenta do RoundCut. Use o Remover Fundo uma vez em uma imagem pequena para que o modelo ISNet no navegador fique em cache.
- Abra o DevTools → Network → marque Offline (ou desligue o Wi-Fi).
- Recarregue a página, os arquivos estáticos estão em cache, então ela ainda carrega.
- Teste as ferramentas:
- Ferramentas só de navegador (Recorte em Círculo, redimensionamento, a pré-visualização da compressão) continuam funcionando, elas nunca precisaram da rede.
- Download da Compressão recorre ao blob de pré-visualização no navegador (codificação um pouco menos eficiente, mas funcional).
- Remover Fundo recorre ao modelo ISNet em WebAssembly e funciona sem nenhuma requisição de saída.
Se as ferramentas funcionaram offline (as apoiadas na nuvem um pouco degradadas, as só de navegador idênticas), por definição nenhum servidor viu sua imagem.
O que vemos, e o que não vemos
Nos caminhos do lado do cliente, não vemos nada sobre sua imagem. Não há requisição para olhar, nem cache para guardá-la, nem linha de log para procurar.
Nos caminhos do lado do servidor:
- O serviço de compressão e PDF vê os bytes da imagem pela duração da codificação (tipicamente algumas centenas de milissegundos), mantém uma entrada de cache endereçada por conteúdo pelo TTL do cache, e é só. O cache não é indexado por usuário, IP, nome de arquivo ou qualquer identificador que pudéssemos usar para achar as “suas” imagens. Não registramos o conteúdo da imagem. O serviço de codificação é compartilhado entre os mesmos dois inquilinos que a v1 servia antes da migração, com CORS por inquilino, limites de taxa e URLs canônicas assinadas por HMAC.
- O Remover Fundo e os outros caminhos de IA veem a imagem pela duração do envio temporário e da chamada do modelo (tipicamente alguns segundos), depois dos quais a cópia temporária é apagada por uma regra de ciclo de vida do R2. O modelo BiRefNet roda dentro da própria infraestrutura da Cloudflare, não em uma API externa no estilo remove.bg / fal.ai / Replicate.
Em todo caminho, nosso provedor de analytics (Cloudflare Web Analytics) registra dados agregados de visualização de página. URL, país, família de navegador, Core Web Vitals. Sem cookies, sem identificadores persistentes, nada ligado a uma pessoa.
Para as ferramentas que baixam um módulo WebAssembly no primeiro uso (o decodificador HEIC, o modelo ISNet ONNX), nosso provedor de hospedagem vê que alguém buscou o módulo, do mesmo jeito que vê alguém buscar o arquivo CSS. O módulo em si não contém nenhuma informação sobre sua imagem.
O inventário completo de dados está na nossa política de privacidade.
A pilha de tecnologia
Para os curiosos:
- Astro, o gerador de site estático. Cada página é entregue como HTML puro com “ilhas” de JavaScript com aprimoramento progressivo só onde vivem as ferramentas interativas.
- CSS puro com propriedades personalizadas, sem Tailwind, sem CSS-in-JS. Todo o sistema de design é um único arquivo
tokens.css. canvas.toBlob/<canvas>. Codificação em JPEG, PNG, WebP, AVIF (suportada pelo navegador) nas ferramentas só de navegador, e todo o trabalho de recorte e redimensionamento.- Cropper.js, a camada de interação do retângulo de recorte.
- ONNX Runtime Web, roda o fallback ISNet em WebAssembly para o Remover Fundo.
- Cloudflare Pages, hospeda o build estático, serve a partir da borda.
- Cloudflare Workers + R2 +
cf.image.segment(BiRefNet), o pipeline padrão do Remover Fundo. - Fastify +
sharp 0.34+libvips 8.17no Node 24, o serviço de compressão e PDF emapi.roundcut.com.br, em um VPS da Hostinger na Alemanha. - Cloudflare Web Analytics, contagens agregadas de visualização de página, sem cookies.
Suporte de navegador
Toda ferramenta funciona na versão atual e na anterior do Chrome, Firefox, Safari e
Edge, no desktop e no celular. O site usa aprimoramento progressivo: onde um
navegador suporta uma API mais nova (por exemplo showSaveFilePicker,
OffscreenCanvas), nós a usamos, onde não suporta, recorremos ao equivalente mais
antigo. Não há nenhuma barreira do tipo “seu navegador não é suportado”.
Os únicos requisitos rígidos são JavaScript (para qualquer ferramenta) e uma conexão de rede (só ao usar uma ferramenta apoiada na nuvem no caminho padrão dela, as ferramentas só de navegador rodam por completo offline depois do primeiro carregamento da página).
Dúvidas
Tem algo que não cobrimos? Escreva para suporte@roundcut.com.br. Perguntas técnicas são bem-vindas.