Conversor de Imagem para WebP

Image to WebP converte JPG, PNG, GIF, BMP e outros arquivos de imagem para o formato WebP. Os arquivos são enviados para o serviço de conversão WebP do ToolAct, que usa libwebp no servidor (via libvips) para fazer a codificação e depois transmite o resultado de volta para o navegador. O upload temporário é excluído do servidor imediatamente após a conversão — não é arquivado nem usado para treinamento. Criado para a web, o WebP costuma gerar arquivos menores para fotos e gráficos, com suporte a transparência e modos com ou sem perda conforme as configurações. Ele é útil para páginas mais rápidas, uploads menores, menos banda e otimização moderna de assets. WebP não é automaticamente a melhor escolha em todos os casos: clientes antigos, fluxos de impressão, exigências de metadados ou softwares de edição podem preferir PNG, JPG ou outro formato. Depois da conversão, nitidez, transparência, cor e tamanho devem ser avaliados juntos.

WebP é um formato contêiner da Google construído sobre três codecs internos: VP8 para imagens estáticas com perda, VP8L para sem perda e VP8X como contêiner estendido que adiciona canal alfa, animação, perfil ICC e blocos EXIF. O WebP com perda aplica predição intra-frame do VP8 com DCT de 4 blocos, desbloqueio em loop e codificação aritmética; o WebP sem perda executa transformações de espaço de cor e um esquema de referência LZ77 sobre o resíduo. Comparado ao JPEG com o mesmo SSIM, o WebP com perda é em média 25-35% menor, e o WebP sem perda é em média 26% menor que o PNG. A conversão nesta ferramenta acontece no servidor. O navegador empacota cada imagem em um upload multipart assinado para o endpoint /image/convert/webp do ToolAct. O servidor encaminha os bytes para o libvips, que decodifica a fonte (PNG, JPEG, GIF, BMP, TIFF) e entrega o buffer de pixels ao libwebp — o codificador de referência do Google. O controle deslizante de qualidade mapeia diretamente para o parâmetro -q do libwebp (0-100): valores abaixo de 100 escolhem o caminho VP8 com perda, com subamostragem de crominância 4:2:0 e faixa de 8 bits por canal, e qualidade 100 muda para o caminho VP8L sem perda, que preserva cada pixel exatamente. O codificador grava o bitstream em um contêiner WebP RIFF (Resource Interchange File Format), opcionalmente adicionando o chunk estendido VP8X para alfa ou ICC, e o resultado é transmitido de volta como corpo da resposta. O arquivo de upload temporário é excluído do servidor assim que a resposta é finalizada — não é arquivado nem usado para treinamento. O suporte já é amplo o suficiente para atuar como substituto do JPEG: Chrome 32+, Edge 18+, Firefox 65+ e Safari 14+ incluem o decodificador. Os casos restantes são previsíveis. O WebP com perda força pixels transparentes para RGBA 0,0,0,0 porque a crominância 4:2:0 não suporta alfa parcial com fidelidade total. Qualidade abaixo de ~70 começa a mostrar posterização em céus uniformes e dessaturação de vermelhos e amarelos em cores de marca, por isso fotos de produto geralmente ficam na faixa de 80-85. WebP animado pode ser criado através das ferramentas mux do libwebp, mas o cenário típico é de imagens estáticas, então a conversão de GIFs animados requer instrução explícita ao codificador para preservar todos os quadros.

• Contêiner: VP8 com perda, VP8L sem perda, VP8X estendido (alfa, animação, ICC, EXIF); os três layouts compartilham o mesmo wrapper RIFF.
• Pipeline no servidor: libvips decodifica a fonte, libwebp codifica a saída. O controle deslizante de qualidade mapeia para o parâmetro -q do libwebp; quality=100 seleciona o caminho VP8L sem perda, valores menores escolhem VP8 com perda e crominância 4:2:0.
• Proporções de tamanho: cerca de 25-35% menor que JPEG com o mesmo SSIM, cerca de 26% menor que PNG para sem perda com transparência.
• Tratamento de alfa: WebP com perda achata pixels totalmente transparentes para RGBA 0,0,0,0; preserve o alfa real escolhendo o modo sem perda ou mantendo PNG para ícones.
• Linha de base dos navegadores: Chrome 32+, Edge 18+, Firefox 65+, Safari 14+/iOS 14+; dispositivos antigos restritos que não podem ser atualizados ainda precisam de fallback PNG/JPG.
• Ciclo de vida da conversão: cada arquivo enviado é mantido apenas pelo tempo necessário para executar a codificação libwebp e transmitir o resultado de volta. O arquivo temporário é excluído ao fechamento da resposta, independentemente de a conversão ter sido bem-sucedida ou não.