O nascimento do PNG: como uma guerra de patentes criou o formato sem perdas favorito da web

Abra um arquivo PNG em um editor hexadecimal. Os primeiros oito bytes:

89 50 4E 47 0D 0A 1A 0A

Essa é a assinatura PNG. Todo decodificador de PNG a verifica. O primeiro byte, 0x89, foi deliberadamente escolhido alto — ele impede que editores de texto ingênuos tratem o arquivo como ASCII. 50 4E 47 soletra "PNG" em ASCII. 0D 0A é uma quebra de linha DOS, 1A é o marcador de fim de arquivo do DOS e 0A é um line feed Unix. Os projetistas embutiram esses caracteres de quebra de linha para que transferências por FTP em modo texto corrompessem o arquivo imediatamente, forçando os usuários a transferir em modo binário. Foi um pequeno ato de paranóia de desenvolvedores que tinham acabado de ver um formato patenteado virar uma arma legal.

O PNG está em toda parte hoje. Ele alimenta capturas de tela, recursos de interface, diagramas, logotipos e qualquer imagem onde os pixels precisam ficar exatamente iguais após salvamentos repetidos. É mais velho que o Google, mais velho que o iPod, e ainda é a escolha padrão quando a compressão sem perdas importa. Mas ele nunca foi destinado a ser um formato. Começou como uma solução paliativa, não como um padrão.

O processo que forçou um novo formato

Em janeiro de 1995, a Unisys anunciou que faria valer sua patente de compressão LZW — a Patente dos EUA 4.558.302 — contra desenvolvedores que usassem o formato GIF. A patente cobria o algoritmo Lempel-Ziv-Welch, o método de compressão no coração de cada codificador e decodificador de GIF.

A web rodava em cima do GIF em 1995. Banners animados, logotipos transparentes, fundos em mosaico — o GIF fazia tudo isso. Então a Unisys exigiu royalties. Fornecedores de software comercial enfrentaram taxas de licenciamento. Projetos de código aberto enfrentaram ameaças existenciais. O GNU Image Manipulation Program (GIMP) foi diretamente afetado. A comunidade de desenvolvimento web estava furiosa.

Algo precisava substituir o GIF para imagens estáticas. Os requisitos eram claros: sem patentes, compressão melhor que a do GIF, suporte a cor verdadeira e um canal alfa adequado em vez da transparência tosca de uma única cor do GIF. Também precisava ser simples o suficiente para que um único desenvolvedor pudesse implementar um decodificador em um fim de semana.

Em 4 de abril de 1995, Thomas Boutell publicou uma proposta no newsgroup Usenet comp.graphics. Ele a chamou de PBF — Portable Bitmap Format. O nome não pegou. Nos meses seguintes, uma lista de e-mails se formou. Os colaboradores incluíam Tom Lane (líder do Independent JPEG Group), Lee Daniel Crocker, Alexander Lehmann e dezenas de outros. Até 1º de outubro de 1996, a especificação do PNG foi congelada como RFC 2083. Todo o processo levou aproximadamente dezoito meses, da ideia ao padrão. Para comparar, o JPEG levou seis anos.

O que existia antes do PNG

Em 1995, suas opções de formato de imagem eram limitadas e cada uma carregava lastro:

GIF dominava a web, mas era legalmente tóxico. Sua paleta de 256 cores servia para ícones e desenhos animados, mas era inútil para fotografias. Sua transparência era binária: um pixel era totalmente opaco ou totalmente transparente. Sem bordas suaves, sem sombras projetadas.

JPEG lidava com fotografias brilhantemente, mas destruía dados de forma irreversível. Abra um JPEG, edite-o, salve novamente e a imagem se degrada. O JPEG também não tinha transparência alguma. Para designers web que precisavam de um logotipo flutuando sobre um fundo texturizado, o JPEG era inútil.

BMP e PCX eram descompactados ou quase isso. Um BMP de 640 × 480 em 1995 consumia 900 KB. Em um modem de 28,8 kbps, isso levava mais de quatro minutos para baixar.

TIFF era poderoso e flexível, mas sua flexibilidade era sua maldição. Arquivos TIFF podiam usar uma dúzia de esquemas de compressão, espaços de cor e profundidades de bits. Escrever um decodificador universal de TIFF era um projeto de nível de tese, não um hack de fim de semana.

O PNG foi projetado para acertar um alvo estreito: substituir o GIF para imagens estáticas, superar sua compressão, adicionar cor verdadeira e transparência real, e permanecer livre para sempre.

Como o PNG realmente comprime

A compressão do PNG é um pipeline de dois estágios. Nenhum dos dois passos é especial por si só. Juntos, funcionam de forma surpreendentemente eficaz.

Estágio 1: Filtragem

Antes de qualquer compressão, o PNG passa os dados brutos de pixel por um filtro. O filtro não comprime nada. Ele rearranja os dados para que o estágio seguinte possa comprimi-los melhor.

Uma imagem é uma grade de bytes. Em uma fotografia de um céu claro, pixels adjacentes são quase idênticos. Mas o fluxo de bytes bruto ainda armazena 120, 121, 120, 122, 119 para cada canal. As diferenças são mínimas: +1, -1, +2, -3. Se você armazenar as diferenças em vez dos valores absolutos, os números resultantes se agrupam em torno de zero. Esse agrupamento é o que algoritmos de compressão adoram.

O PNG define cinco tipos de filtro por linha de varredura:

O codificador testa os cinco filtros por linha de varredura e escolhe aquele que produz a saída menor após o Estágio 2. É por isso que um codificador de PNG pode ser lento: ele está fazendo uma busca de força bruta sobre combinações de filtros. Mas a decodificação é rápida — o tipo de filtro é armazenado no arquivo, então o decodificador apenas aplica a operação inversa.

Estágio 2: DEFLATE

Depois da filtragem, os dados são comprimidos com DEFLATE, o mesmo algoritmo usado pelo gzip e por arquivos ZIP. O DEFLATE é uma combinação de LZ77 (eliminação de strings duplicadas em janela deslizante) e codificação Huffman (códigos de prefixo de comprimento variável para símbolos frequentes).

O resultado: uma captura de tela ou gráfico de interface típico comprime 3–5× menor que um BMP descompactado. Uma fotografia comprimida como PNG é geralmente 5–10× maior que um JPEG, mas cada pixel é recuperável. A compressão é sem perdas por construção: nenhum dado é descartado, apenas redundâncias são removidas.

Para contextualizar, uma captura de tela de 1920 × 1080 em RGB bruto tem 6,2 MB. A mesma captura como PNG tipicamente cai para 800 KB – 1,5 MB. A mesma imagem como JPEG qualidade 90 é 300–500 KB, mas salvá-la novamente dez vezes introduziria artefatos visíveis.

Os recursos que fizeram diferença

O PNG não era apenas um clone livre de patentes do GIF. Ele adicionou capacidades que designers web vinham pedindo desde 1993.

Cor verdadeira: O PNG suporta RGB de 24 bits (16,7 milhões de cores) e cor profunda de 48 bits. Sem limites de paleta. Uma fotografia PNG pode exibir cada cor que o olho humano consegue distinguir.

Canal alfa: O PNG suporta alfa de 8 bits — 256 níveis de transparência por pixel. Uma sombra pode desvanecer suavemente de opaca para transparente. Um botão arredondado pode fazer anti-aliasing contra qualquer fundo. O GIF oferecia transparência de 1 bit: uma cor estava totalmente ligada ou totalmente desligada. A diferença visual é de dia para noite.

Entrelaçamento Adam7: O PNG pode armazenar pixels em uma ordem entrelaçada de 7 passadas. Um navegador renderiza uma pré-visualização grosseira após receber 1/64 do arquivo, e então a refina progressivamente. Ao contrário do entrelaçamento linha por linha do GIF, o Adam7 espalha detalhes por toda a imagem desde a primeira passada. Na terceira passada, a imagem é reconhecível. Na sétima, é perfeita.

Correção gama: O PNG armazena um valor gama em seus metadados. Uma imagem criada em um Mac (gama 1.8) é exibida corretamente em um PC Windows (gama 2.2) sem correção de cor manual. Isso era um problema genuíno nos anos 1990, quando consistência entre plataformas era rara.

Checksums CRC: Cada chunk de PNG carrega um checksum CRC-32. Downloads corrompidos são detectados imediatamente em vez de produzir uma imagem meio renderizada.

Detectando PNG lendo a assinatura do arquivo

Não confie na extensão .png. Leia os primeiros oito bytes e verifique a assinatura.

Layout exato de bytes:

Bytes 0–7:   Assinatura 89 50 4E 47 0D 0A 1A 0A
Bytes 8–11:  Tamanho do chunk (uint32 big-endian)
Bytes 12–15: Tipo do chunk: "IHDR" (cabeçalho da imagem)
Bytes 16–19: Largura da imagem (uint32 big-endian)
Bytes 20–23: Altura da imagem (uint32 big-endian)
Byte 24:     Profundidade de bits
Byte 25:     Tipo de cor
Byte 26:     Método de compressão (sempre 0)
Byte 27:     Método de filtro (sempre 0)
Byte 28:     Método de entrelaçamento (0 ou 1)

TypeScript no navegador:

async function isPng(file: File): Promise<boolean> {
  const buffer = await file.slice(0, 8).arrayBuffer()
  const bytes = new Uint8Array(buffer)

  const signature = [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]
  return bytes.length === 8 && bytes.every((b, i) => b === signature[i])
}

Python

def is_png(path: str) -> bool:
    with open(path, "rb") as f:
        header = f.read(8)

    return header == b"\x89PNG\r\n\x1a\n"

Opção de nível mais alto com a biblioteca padrão:

import imghdr

if imghdr.what("image.png") == "png":
    pass

Ou com Pillow:

from PIL import Image

try:
    with Image.open("image.png") as img:
        is_png = img.format == "PNG"
except Exception:
    is_png = False

Go

func isPng(path string) bool {
	f, err := os.Open(path)
	if err != nil {
		return false
	}
	defer f.Close()

	buf := make([]byte, 8)
	if _, err := f.Read(buf); err != nil {
		return false
	}

	return bytes.Equal(buf, []byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a})
}

PHP

function isPng(string $path): bool {
    $header = file_get_contents($path, false, null, 0, 8);
    return $header === "\x89PNG\r\n\x1a\n";
}

Com fileinfo:

$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file('image.png');
// image/png

ImageMagick CLI

magick identify -verbose image.png | grep "Format:"
# Format: PNG (Portable Network Graphics)

Ou simplesmente:

file image.png
# image.png: PNG image data, 1200 x 675, 8-bit/color RGBA, non-interlaced

As limitações do PNG

O PNG não é perfeito. Suas escolhas de design foram concessões, e algumas dessas concessões ainda nos custam hoje.

Sem animação embutida: O Grupo de Trabalho do PNG rejeitou explicitamente a animação. Eles queriam resolver completamente o problema da imagem estática antes de adicionar complexidade. O resultado: o GIF animado sobreviveu por mais duas décadas. O APNG (Animated PNG) foi eventualmente padronizado em 2004, mas o suporte nos navegadores permaneceu irregular até o final dos anos 2010. Mesmo hoje, GIFs animados superam APNGs em ordens de magnitude.

Tamanhos de arquivo grandes para fotografias: Uma fotografia de 12 MP como PNG tipicamente tem 15–25 MB. Como JPEG qualidade 90, tem 3–5 MB. A compressão sem perdas do PNG não consegue competir com o descarte psicovisual baseado em DCT do JPEG. Para fotografias, o PNG é a ferramenta errada.

Sem suporte a CMYK: O PNG é apenas RGB. Fluxos de trabalho de impressão que exigem separação CMYK devem converter PNG para TIFF ou JPEG. Isso foi uma escolha deliberada — os projetistas focaram na tela, não na impressão — mas limita a utilidade do PNG na publicação profissional.

Decodificação mais lenta que JPEG: A decodificação de PNG requer filtragem inversa por linha de varredura e descompressão DEFLATE. A decodificação de JPEG é altamente paralelizável e fortemente otimizada em hardware. Em dispositivos móveis, um PNG grande pode levar 2–3× mais tempo para renderizar do que um JPEG de resolução equivalente, atrasando o Largest Contentful Paint.

Sem qualidade progressiva: Diferentemente do JPEG 2000 ou JPEG XL, o PNG não pode produzir uma pré-visualização de menor qualidade a partir de um arquivo truncado. Ou você tem o arquivo inteiro, ou não tem nada. O entrelaçamento Adam7 ajuda com pré-visualizações grosseiras, mas não reduz o tamanho total do arquivo.

Por que o PNG nunca substituiu o JPEG

Esse é o mal-entendido mais comum sobre formatos de imagem. PNG e JPEG nunca competiram pelo mesmo emprego.

O JPEG é um compressor psicovisual com perdas. Ele descarta dados que seus olhos provavelmente não notariam. Foi projetado para fotografias de tom contínuo — imagens com gradientes suaves, textura fina e iluminação natural. Para esse trabalho, o JPEG ainda é imbatível na curva tamanho-qualidade após trinta e três anos.

O PNG é um compressor de dados sem perdas. Ele preserva cada bit. Foi projetado para imagens de tom discreto — capturas de tela, elementos de interface, diagramas, logotipos, sobreposições de texto — onde bordas nítidas e cores exatas importam. Para esse trabalho, o PNG é o padrão.

Os dois formatos se dividiram em territórios separados:

O PNG nunca tentou substituir o JPEG. Só encontrou um trabalho diferente.

Onde o PNG se posiciona hoje

O Web Almanac 2025 coloca o PNG em aproximadamente 22% de todas as imagens servidas na web. Isso é menos que no auge — WebP e AVIF estão comendo fatia — mas o PNG permanece o formato de fallback que todo navegador, todo editor de imagens e todo sistema operacional pode abrir sem hesitação.

WebP (Google, 2010) suporta modos com e sem perdas, além de animação e transparência. Um WebP sem perdas é tipicamente 20–30% menor que um PNG equivalente. O suporte nos navegadores é universal desde 2020. Para projetos novos, o WebP sem perdas é o substituto pragmático do PNG na maioria dos casos.

AVIF (AOM, 2019) alcança compressão ainda melhor, mas seu modo sem perdas é mais lento para codificar e decodificar que o PNG. O AVIF também carece de suporte completo nos navegadores para alguns recursos avançados do PNG como canais de 16 bits e correção gama embutida.

SVG domina o espaço de ícones e logotipos para gráficos vetoriais simples, mas gráficos rasterizados complexos ainda precisam de PNG.

A realidade prática: o PNG não vai desaparecer. Ele é a opção segura padrão, o formato para o qual você exporta quando precisa garantir que o destinatário consiga abrir o arquivo. Ele é o QWERTY dos formatos de imagem — não é ótimo, mas é universalmente compreendido.

O futuro do PNG

O PNG é um padrão acabado. A especificação não mudou significativamente desde 2003. Essa estabilidade é um recurso, não um bug. Você pode abrir um PNG criado em 1997 em qualquer navegador moderno e ele será renderizado identicamente.

Mas o ecossistema ao redor do PNG continua evoluindo:

APNG está ganhando terreno. O Safari o suporta desde 2014. Chrome e Firefox seguiram. Discord, Slack e Twitter todos renderizam APNGs nativamente. Para animações curtas de interface — spinners de carregamento, emojis de reação, indicadores de status — o APNG está substituindo o GIF animado com arquivos menores e melhor fidelidade de cor.

Ferramentas de otimização de PNG continuam melhorando. oxipng, pngcrush e zopfli podem reduzir mais 10–30% dos tamanhos de arquivo PNG ao forçar busca por melhores combinações de filtros e parâmetros DEFLATE. Para sites de alto tráfego, passar cada PNG pelo oxipng é prática padrão.

PNG como contêiner: alguns fluxos de trabalho modernos embutem perfis de cor ICC, metadados EXIF e até dados XMP dentro de chunks de PNG. O PNG se tornou um formato de arquivo leve — não tão rico quanto o TIFF, mas muito mais portátil.

A perspectiva de longo prazo: O PNG coexistirá com WebP, AVIF e JPEG XL por anos. Ele preenche um nicho que nenhum outro formato possui completamente: sem perdas, livre de patentes, universalmente suportado, e simples o suficiente para que um único desenvolvedor possa escrever um decodificador a partir da especificação em uma semana. Essa combinação é difícil de deslocar.

A conclusão

O PNG foi criado porque os desenvolvedores estavam de saco cheio. Um processo de patente ameaçou a web aberta, e um grupo de desenvolvedores construiu uma alternativa no tempo livre. Eles não se propuseram a criar um padrão de trinta anos. Eles se propuseram a resolver um problema: como colocar um logotipo transparente em uma página web sem pagar uma taxa de licença.

O resultado foi muito melhor do que qualquer um esperava. O PNG deu à web gráficos de cor verdadeira, transparência suave e integridade de arquivo resistente à corrupção. Ele provou que padrões abertos, construídos por voluntários, podiam superar formatos proprietários apoiados por grandes empresas.

Ele não é o formato menor. Não é o mais rápido de decodificar. Não faz animação bem, e é inútil para fotografias. Mas quando você precisa saber que cada pixel que salvou é o pixel que receberá de volta — o PNG ainda é a ferramenta que você usa.

Nem toda imagem nasce como PNG. Se você tem JPGs que precisam de transparência ou edição sem perdas, pode convertê-los diretamente no navegador — sem instalar nada, sem que nada saia do seu dispositivo. JPG para PNG faz isso localmente. Para projetos web onde o tamanho do arquivo pesa, JPG para WebP reduz o peso sem mexer na qualidade. E quando você precisa de ícones favicon, JPG para ICO transforma fotos em arquivos ICO em vários tamanhos.