Compressão JPEG, PNG e WebP não é o mesmo problema
A estratégia correta depende do formato e da propriedade que precisa ser preservada. JPEG normalmente troca alguma fidelidade por arquivos menores, PNG pode ser otimizado sem alterar pixels e WebP pode conter dados com ou sem perdas conforme a origem e o codificador.
Última revisão técnica: 2026-09-19
Principais conclusões
- Uma imagem menor não é automaticamente equivalente à original.
- Dimensões, transparência alfa, formato e metadados são propriedades diferentes e precisam de decisões explícitas.
- Recodificar costuma remover metadados originais mesmo quando largura e altura são preservadas.
- Um compressor verificado deve decodificar ou inspecionar a própria saída antes de oferecê-la.
JPEG: recompressão com perdas e limites
JPEG é voltado a imagens fotográficas e normalmente usa compressão com perdas. Recodificar com qualidade menor pode economizar bytes mantendo as mesmas dimensões, mas parte da informação visual é descartada.
Recompressões JPEG repetidas podem acumular artefatos; por isso um compressor deve usar uma estratégia limitada de qualidade e parar em vez de degradar indefinidamente.
PNG: pixels sem perdas e escolhas estruturais
PNG suporta dados de imagem sem perdas e transparência alfa. Um otimizador sem perdas pode reorganizar scanlines ou filtros sem alterar os pixels decodificados.
Nem toda variante PNG é igualmente simples de tratar. Paletas, entrelaçamento, profundidades altas e chunks incomuns podem exigir suporte separado.
WebP: suporte ao formato e comportamento do encoder importam
WebP suporta vários modos de codificação, inclusive transparência. O encoder nativo do navegador pode tratar metadados de forma diferente da origem e isso não significa que todo recurso possível de WebP seja preservado.
Um compressor focado precisa definir variantes suportadas, preservar dimensões e comportamento alfa exigidos e confirmar que a saída é realmente WebP.
Como a ZAMAZY separa as ferramentas
A ZAMAZY usa compressores separados para JPEG, PNG e WebP em vez de um botão genérico. Cada ferramenta tem regras próprias de suporte e verificação.
JPEG aceita explicitamente recompressão com perdas, PNG prioriza preservação sem perdas dos pixels e WebP é verificado como WebP com dimensões e transparência esperadas no subconjunto suportado.
Exemplo e apoio à decisão
Uma fotografia, uma captura de tela com texto pequeno e um logotipo transparente têm prioridades diferentes. JPEG pode servir para fotografias quando alguma perda é aceitável; PNG sem perdas é útil quando pixels decodificados e alfa precisam permanecer exatos. WebP admite vários modos, mas o compressor WebP da ZAMAZY usa recodificação com perdas e limites, não todos os modos permitidos pelo formato.
Escolha o compressor que corresponde ao formato atual do arquivo. Essas ferramentas focadas não são conversores de formato nem ferramentas de redimensionamento. Compare bordas de texto, gradientes, cor e limites transparentes no resultado. Largura e altura iguais não provam pixels RGB idênticos. Um valor de qualidade é uma configuração do encoder, não uma nota visual universal nem uma porcentagem comparável entre navegadores.
Quando esta abordagem não é adequada
Preservar alfa não prova preservação de perfis de cor, animação ou todo campo de metadados. Uma entrada já bem comprimida pode não produzir resultado menor aceitável. Se forem exigidos pixels exatos, animação, fluxo de cor para impressão ou outro formato específico, não substitua isso por compressão com perdas só porque a extensão é suportada.
Exemplo editorial, não um benchmark. Complemento revisado em:
Fontes e limites das evidências
Estas fontes explicam formatos e métodos. Elas não certificam a ZAMAZY; os fatos e limites suportados pela ZAMAZY estão na página de cada ferramenta.
- MDN: Image file type and format guide — Trade-offs entre formatos; capacidades de um formato não implicam suporte da ferramenta.
- W3C: PNG Specification, Third Edition — Pixels PNG, alfa e chunks; não é uma alegação de que toda variante PNG seja aceita.
- Google: WebP Container Specification — Modos WebP, alfa, animação e contêineres de metadados.
- MDN: HTMLCanvasElement.toBlob() — Formato de codificação e parâmetros de qualidade; não é uma alegação certificada de remoção de metadados.
Estudo próprio do fabricante: preservação PNG sem perdas
Status: verificado. A ZAMAZY processou três arquivos PNG fixos e totalmente sintéticos com a engine PNG inalterada e depois decodificou e comparou estruturalmente cada resultado.
Este é um estudo próprio do fabricante, não uma certificação independente. As entradas, deliberadamente fáceis de comprimir, foram criadas com nível 0 de compressão zlib e por isso não representam um benchmark típico de compressão.
| Fixture | Dimensões | Entrada | Saída | Preservação verificada |
|---|---|---|---|---|
rgb-flat-v1 | 256 × 64 | 49.284 B | 252 B | Scanlines idênticas; chunks não-IDAT idênticos; segunda passagem recusada quando não produziu uma saída menor |
rgba-pattern-v1 | 64 × 32 | 8.292 B | 4.700 B | Scanlines idênticas; chunks não-IDAT idênticos; alfa idêntico; segunda passagem recusada quando não produziu uma saída menor |
gray-metadata-v1 | 64 × 32 | 2.199 B | 158 B | Scanlines idênticas; chunks não-IDAT idênticos; segunda passagem recusada quando não produziu uma saída menor |
Casos negativos
No ambiente verificado, dados zlib truncados, checksum Adler-32 inválido e dados extras após o stream zlib foram recusados.
truncated-zlib: recusadoinvalid-adler32: recusadotrailing-zlib-data: recusado
Método e limites
O estudo comparou scanlines decodificadas, geometria e todos os chunks não-IDAT antes e depois da otimização; no caso RGBA, o alfa foi verificado explicitamente. A descompressão de controle separada usou Node zlib e não é um verificador externo independente.
A evidência vale apenas para as fixtures documentadas e a versão indicada da engine. Ela não prova todas as variantes PNG, comportamento de rede do navegador, suporte de dispositivos, taxas típicas de compressão ou segurança para arquivos arbitrários de usuários.
Estudo png-preservation-v1 · revisado em · Node 22.22.3 / zlib 1.3.1-e00f703 / linux x64 ·commit da engine a12415a3a19f
Perguntas frequentes
PNG é sempre maior que JPEG?
Não. Depende da imagem. Fotografias frequentemente favorecem JPEG, enquanto gráficos planos, imagens com texto e transparência podem favorecer PNG.
Manter as mesmas dimensões significa que a imagem é sem perdas?
Não. Largura e altura podem ficar iguais enquanto JPEG ou WebP com perdas descarta informação visual durante a codificação.
Por que metadados podem desaparecer depois da compressão?
A recodificação no navegador normalmente cria um novo stream de imagem em vez de copiar o contêiner original. EXIF, GPS e outros metadados precisam de suporte explícito para serem preservados.