El nacimiento de PNG: cómo una guerra de patentes creó el formato sin pérdidas favorito de la web

Abre un archivo PNG en un editor hexadecimal. Los primeros ocho bytes:

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

Esa es la firma PNG. Todo decodificador de PNG la verifica. El primer byte, 0x89, se eligió a propósito alto: evita que editores de texto ingenuos traten el archivo como ASCII. 50 4E 47 deletrea "PNG" en ASCII. 0D 0A es un fin de línea DOS, 1A es el marcador de fin de archivo DOS y 0A es un salto de línea Unix. Los diseñadores incrustaron estos caracteres de fin de línea para que las transferencias por FTP en modo texto corrompieran el archivo de inmediato, forzando a los usuarios a transferir en modo binario. Fue un exceso de precaución por parte de desarrolladores que acababan de ver cómo un formato con patente se convertía en un arma legal.

Hoy PNG está en todas partes. Alimenta capturas de pantalla, recursos de interfaz, diagramas, logotipos y cualquier imagen donde los píxeles deben sobrevivir intactos a viajes de ida y vuelta. Es más viejo que Google, más viejo que el iPod, y sigue siendo la opción predeterminada cuando importa la compresión sin pérdidas. Pero al principio no pretendía ser un formato. Empezó como una solución provisional, no como un estándar.

La demanda que obligó a crear un nuevo formato

En enero de 1995, Unisys anunció que haría valer su patente de compresión LZW — la Patente estadounidense 4.558.302 — contra desarrolladores que usaran el formato GIF. La patente cubría el algoritmo Lempel-Ziv-Welch, el método de compresión en el corazón de cada codificador y decodificador de GIF.

En 1995 la web corría sobre GIF. Banners animados, logotipos transparentes, fondos en mosaico: GIF lo hacía todo. Entonces Unisys exigió regalías. Los proveedores de software comercial enfrentaron tarifas de licencia. Los proyectos de código abierto enfrentaron amenazas existenciales. El GNU Image Manipulation Program (GIMP) se vio directamente afectado. La comunidad de desarrollo web estaba furiosa.

Algo tenía que reemplazar a GIF para imágenes estáticas. Los requisitos eran claros: sin patentes, mejor compresión que GIF, soporte para color verdadero y un canal alfa real en lugar de la tosca transparencia de un solo color de GIF. También debía ser lo suficientemente simple para que un solo desarrollador pudiera implementar un decodificador en un fin de semana.

El 4 de abril de 1995, Thomas Boutell publicó una propuesta en el grupo de noticias Usenet comp.graphics. Lo llamó PBF — Portable Bitmap Format. El nombre no pegó. Durante los siguientes meses se formó una lista de correo. Los colaboradores incluían a Tom Lane (líder del Independent JPEG Group), Lee Daniel Crocker, Alexander Lehmann y docenas más. Para el 1 de octubre de 1996, la especificación de PNG se congeló como RFC 2083. Todo el proceso tomó aproximadamente dieciocho meses, de la idea a la norma. Para comparar, JPEG tardó seis años.

Qué existía antes de PNG

En 1995, las opciones de formato de imagen eran limitadas y cada una arrastraba lastre:

GIF dominaba la web pero era legalmente tóxico. Su paleta de 256 colores servía para iconos y dibujos animados, pero era inútil para fotografías. Su transparencia era binaria: un píxel era completamente opaco o completamente transparente. Sin bordes suaves, sin sombras proyectadas.

JPEG manejaba las fotografías brillantemente pero destruía datos de forma irreversible. Abre un JPEG, edítalo, guárdalo de nuevo y la imagen se degrada. JPEG tampoco tenía transparencia alguna. Para diseñadores web que necesitaban un logotipo flotando sobre un fondo texturizado, JPEG era inútil.

BMP y PCX eran formatos sin compresión o apenas comprimidos. Un BMP de 640 × 480 en 1995 consumía 900 KB. En un módem de 28,8 kbps, eso tomaba más de cuatro minutos en descargarse.

TIFF era potente y flexible, pero su flexibilidad era su maldición. Los archivos TIFF podían usar una docena de esquemas de compresión, espacios de color y profundidades de bits. Escribir un decodificador universal de TIFF era un proyecto a nivel de tesis, no un hack de fin de semana.

PNG se diseñó para dar en un blanco estrecho: reemplazar a GIF para imágenes estáticas, superar su compresión, agregar color verdadero y transparencia real, y mantenerse libre para siempre.

Cómo comprime PNG en realidad

La compresión de PNG es una tubería de dos etapas. Ninguna de las dos es especial por sí sola. Juntas funcionan sorprendentemente bien.

Etapa 1: Filtrado

Antes de cualquier compresión, PNG pasa los datos de píxeles crudos por un filtro. El filtro no comprime nada. Reorganiza los datos para que la siguiente etapa pueda comprimirlos mejor.

Una imagen es una cuadrícula de bytes. En una fotografía de un cielo despejado, los píxeles adyacentes son casi idénticos. Pero el flujo de bytes crudo aún almacena 120, 121, 120, 122, 119 para cada canal. Las diferencias son mínimas: +1, -1, +2, -3. Si almacenas las diferencias en lugar de los valores absolutos, los números resultantes se agrupan alrededor de cero. Esa agrupación es lo que los algoritmos de compresión adoran.

PNG define cinco tipos de filtro por línea de escaneo:

El codificador prueba los cinco filtros por línea de escaneo y elige el que produce la salida más pequeña después de la Etapa 2. Por eso un codificador de PNG puede ser lento: está haciendo una búsqueda por fuerza bruta sobre combinaciones de filtros. Pero la decodificación es rápida: el tipo de filtro se almacena en el archivo, así que el decodificador solo aplica la operación inversa.

Etapa 2: DEFLATE

Después del filtrado, los datos se comprimen con DEFLATE, el mismo algoritmo que usan gzip y los archivos ZIP. DEFLATE es una combinación de LZ77 (eliminación de cadenas duplicadas en ventana deslizante) y codificación Huffman (códigos de prefijo de longitud variable para símbolos frecuentes).

El resultado: una captura de pantalla o gráfico de interfaz típico se comprime 3–5× más pequeño que un BMP sin comprimir. Una fotografía comprimida como PNG suele ser 5–10× más grande que JPEG, pero cada píxel es recuperable. La compresión es sin pérdidas por construcción: no se descarta ningún dato, solo se eliminan redundancias.

Para dar contexto, una captura de pantalla de 1920 × 1080 en RGB crudo pesa 6,2 MB. La misma captura como PNG típicamente baja a 800 KB – 1,5 MB. La misma imagen como JPEG calidad 90 es 300–500 KB, pero volver a guardarla diez veces introduciría artefactos visibles.

Las características que importaron

PNG no era solo un clon libre de patentes de GIF. Agregó capacidades que los diseñadores web habían estado pidiendo desde 1993.

Color verdadero: PNG soporta RGB de 24 bits (16,7 millones de colores) y color profundo de 48 bits. Sin límites de paleta. Una fotografía PNG puede mostrar cada color que el ojo humano puede distinguir.

Canal alfa: PNG soporta alfa de 8 bits — 256 niveles de transparencia por píxel. Una sombra puede fundirse suavemente de opaca a transparente. Un botón redondeado puede anti-aliasearse contra cualquier fondo. GIF ofrecía transparencia de 1 bit: un color estaba completamente activo o completamente inactivo. La diferencia visual es abismal.

Entrelazado Adam7: PNG puede almacenar píxeles en un orden entrelazado de 7 pasadas. Un navegador renderiza una vista previa gruesa después de recibir 1/64 del archivo, y luego lo refina progresivamente. A diferencia del entrelazado línea por línea de GIF, Adam7 esparce detalles por toda la imagen desde la primera pasada. Para la tercera pasada, la imagen es reconocible. Para la séptima, es perfecta.

Corrección gamma: PNG almacena un valor gamma en sus metadatos. Una imagen creada en una Mac (gamma 1.8) se muestra correctamente en una PC con Windows (gamma 2.2) sin corrección de color manual. Esto era un problema genuino en los años 90, cuando la consistencia entre plataformas era rara.

Suma de verificación CRC: cada chunk de PNG lleva una suma de verificación CRC-32. Las descargas corruptas se detectan de inmediato en lugar de producir una imagen medio renderizada.

Detectar PNG leyendo la firma del archivo

No confíes en la extensión .png. Lee los primeros ocho bytes y verifica la firma.

Disposición exacta de bytes:

Bytes 0–7:   Firma 89 50 4E 47 0D 0A 1A 0A
Bytes 8–11:  Longitud del chunk (uint32 big-endian)
Bytes 12–15: Tipo de chunk: "IHDR" (encabezado de imagen)
Bytes 16–19: Ancho de imagen (uint32 big-endian)
Bytes 20–23: Alto de imagen (uint32 big-endian)
Byte 24:     Profundidad de bits
Byte 25:     Tipo de color
Byte 26:     Método de compresión (siempre 0)
Byte 27:     Método de filtro (siempre 0)
Byte 28:     Método de entrelazado (0 o 1)

TypeScript en el 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"

Opción de más alto nivel con la biblioteca estándar:

import imghdr

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

O con 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";
}

Con 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)

O simplemente:

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

Las limitaciones de PNG

PNG no es perfecto. Sus decisiones de diseño fueron concesiones, y algunas de esas concesiones aún nos cuestan hoy.

Sin animación integrada: el Grupo de Trabajo de PNG rechazó explícitamente la animación. Querían resolver completamente el problema de imágenes estáticas antes de agregar complejidad. El resultado: GIF animado sobrevivió durante otras dos décadas. APNG (Animated PNG) se estandarizó finalmente en 2004, pero el soporte en navegadores permaneció irregular hasta finales de los 2010. Incluso hoy, los GIF animados superan en órdenes de magnitud a los APNG.

Tamaños de archivo grandes para fotografías: una fotografía de 12 MP como PNG típicamente pesa 15–25 MB. Como JPEG calidad 90, pesa 3–5 MB. La compresión sin pérdidas de PNG no puede competir con el descarte psicovisual basado en DCT de JPEG. Para fotografías, PNG es la herramienta equivocada.

Sin soporte CMYK: PNG es solo RGB. Los flujos de trabajo de impresión que requieren separación CMYK deben convertir PNG a TIFF o JPEG. Esta fue una elección deliberada: los diseñadores se enfocaron en la pantalla, no en la impresión, pero limita la utilidad de PNG en publicación profesional.

Decodificación más lenta que JPEG: la decodificación de PNG requiere filtrado inverso por línea de escaneo y descompresión DEFLATE. La decodificación de JPEG es altamente paralelizable y fuertemente optimizada en hardware. En dispositivos móviles, un PNG grande puede tardar 2–3× más en renderizarse que un JPEG de resolución equivalente, retrasando el Largest Contentful Paint.

Sin calidad progresiva: a diferencia de JPEG 2000 o JPEG XL, PNG no puede producir una vista previa de menor calidad a partir de un archivo truncado. O tienes el archivo completo, o no tienes nada. El entrelazado Adam7 ayuda con vistas previas gruesas, pero no reduce el tamaño total del archivo.

Por qué PNG nunca reemplazó a JPEG

Este es el malentendido más común sobre los formatos de imagen. PNG y JPEG nunca compitieron por el mismo puesto.

JPEG es un compresor psicovisual con pérdidas. Descarta datos que tus ojos probablemente no notarían. Se diseñó para fotografías de tono continuo: imágenes con gradientes suaves, textura fina e iluminación natural. Para ese trabajo, JPEG sigue siendo imbatible en la curva tamaño-calidad después de treinta y tres años.

PNG es un compresor de datos sin pérdidas. Preserva cada bit. Se diseñó para imágenes de tono discreto: capturas de pantalla, elementos de interfaz, diagramas, logotipos, superposiciones de texto — donde los bordes nítidos y los colores exactos importan. Para ese trabajo, PNG es el estándar.

Los dos formatos se repartieron el territorio:

PNG nunca intentó reemplazar a JPEG. Solo encontró un trabajo distinto.

Dónde se sitúa PNG hoy

El Web Almanac 2025 ubica a PNG en aproximadamente el 22% de todas las imágenes servidas en la web. Eso es menos que en su pico — WebP y AVIF le están comiendo cuota — pero PNG sigue siendo el formato de respaldo que todo navegador, todo editor de imágenes y todo sistema operativo puede abrir sin dudar.

WebP (Google, 2010) soporta modos con y sin pérdidas, más animación y transparencia. Un WebP sin pérdidas es típicamente 20–30% más pequeño que un PNG equivalente. El soporte en navegadores es universal desde 2020. Para proyectos nuevos, WebP sin pérdidas es el reemplazo pragmático de PNG en la mayoría de los casos.

AVIF (AOM, 2019) logra una compresión aún mejor, pero su modo sin pérdidas es más lento de codificar y decodificar que PNG. AVIF también carece de soporte completo en navegadores para algunas características avanzadas de PNG como canales de 16 bits y corrección gamma embebida.

SVG domina el espacio de iconos y logotipos para gráficos vectoriales simples, pero los gráficos rasterizados complejos aún necesitan PNG.

La realidad práctica: PNG no va a desaparecer. Es la opción segura por defecto, el formato al que exportas cuando necesitas garantizar que el destinatario puede abrir el archivo. Es el QWERTY de los formatos de imagen: no es óptimo, pero es universalmente entendido.

El futuro de PNG

PNG es un estándar terminado. La especificación no ha cambiado significativamente desde 2003. Esa estabilidad es una característica, no un error. Puedes abrir un PNG creado en 1997 en cualquier navegador moderno y se renderizará idénticamente.

Pero el ecosistema alrededor de PNG sigue evolucionando:

APNG está ganando terreno. Safari lo soporta desde 2014. Chrome y Firefox siguieron. Discord, Slack y Twitter renderizan APNG de forma nativa. Para animaciones cortas de interfaz — spinners de carga, emojis de reacción, indicadores de estado — APNG está reemplazando a GIF animado con archivos más pequeños y mejor fidelidad de color.

Las herramientas de optimización de PNG siguen mejorando. oxipng, pngcrush y zopfli pueden reducir otros 10–30% los tamaños de archivo PNG buscando por fuerza bruta mejores combinaciones de filtros y parámetros DEFLATE. Para sitios de alto tráfico, pasar cada PNG por oxipng es práctica estándar.

PNG como contenedor: algunos flujos de trabajo modernos incrustan perfiles de color ICC, metadatos EXIF e incluso datos XMP dentro de chunks de PNG. PNG se ha convertido en un formato de archivo ligero: no tan rico como TIFF, pero mucho más portable.

La perspectiva a largo plazo: PNG coexistirá con WebP, AVIF y JPEG XL durante años. Ocupa un nicho que ningún otro formato posee completamente: sin pérdidas, libre de patentes, universalmente soportado, y lo suficientemente simple para que un solo desarrollador pueda escribir un decodificador desde la especificación en una semana. Esa combinación es difícil de desplazar.

La conclusión

PNG se creó porque los desarrolladores estaban hartos. Una demanda de patentes amenazó la web abierta, y un grupo de desarrolladores construyó una alternativa en su tiempo libre. No se propusieron crear un estándar de treinta años. Se propusieron resolver un problema: cómo poner un logotipo transparente en una página web sin pagar una tarifa de licencia.

El resultado fue mucho mejor de lo que nadie esperaba. PNG le dio a la web gráficos de color verdadero, transparencia suave e integridad de archivo resistente a la corrupción. Demostró que los estándares abiertos, construidos por voluntarios, podían superar a formatos propietarios respaldados por grandes empresas.

No es el formato más pequeño. No es el más rápido de decodificar. No hace bien la animación, y es inútil para fotografías. Pero cuando necesitas saber que cada píxel que guardaste es el píxel que recuperarás — PNG sigue siendo la herramienta a la que recurres.

No toda imagen empieza como PNG. Si tienes JPGs que necesitan transparencia o edición sin pérdidas, puedes convertirlos directamente en tu navegador — sin instalar nada, sin que salga nada de tu dispositivo. JPG a PNG lo hace en local. Cuando el tamaño del archivo importa en un proyecto web, JPG a WebP reduce el peso sin tocar la calidad. Y si necesitas iconos favicon, JPG a ICO convierte fotos en archivos ICO de distintos tamaños.