PNG

Lossless compression

PNG uses lossless compression via DEFLATE (LZ77 + Huffman coding) encapsulated in zlib, allowing exact reconstruction of the original pixels. Before compression, each scanline is transformed by a filter to reduce spatial redundancy and make patterns more compressible. These steps preserve image fidelity while aiming to reduce entropy, particularly effective for graphics with uniform areas, sharp boundaries, and repeated colour runs.

Filtering and predictors

Each row may use one of five predictors (None, Sub, Up, Average, Paeth). These filters reference neighbouring pixels within the current or previous row to predict the next value, then encode only the difference. The encoder can choose the most efficient filter per row, improving compressibility without altering the image. The choice of filter strategy can noticeably affect size; encoders that try multiple filters or heuristics typically achieve smaller files.

Interlacing and structure

PNG stores data in chunks (IHDR, PLTE, IDAT, IEND and ancillary chunks). Optional Adam7 interlacing allows a coarse-to-fine rendering pattern but tends to increase file size and can slow decoding due to multiple passes. Integrity is protected with CRCs per chunk. Ancillary metadata (e.g., colour profiles, gamma, text) can aid fidelity and accessibility but may add overhead if not curated for the delivery context.

Suitable use cases and limits

PNG suits assets that benefit from exact pixel representation: logos and icons with crisp edges, UI controls, diagrams, charts, line art, text overlays, and screenshots. It also supports true alpha transparency, enabling soft edges and drop shadows without matte artefacts. Where colours are limited, indexed-colour PNG (often called PNG‑8) can deliver compact files by referencing a palette rather than storing full 24‑bit colour per pixel.

For photographic or noisy, high-detail imagery, PNG is typically inefficient because lossless storage preserves all granularity, leading to larger files than lossy formats. In those cases, modern lossy codecs (e.g., AVIF or WebP) achieve substantial reductions with visually minimal impact. Animated use is possible via APNG, but broader performance and tooling support often favour alternatives for animations depending on requirements and compatibility targets.

Limits include larger network payloads for photos, increased decode time for very large images, and potentially heavier memory usage on low-end devices. While PNG-24 (truecolour + alpha) ensures fidelity, it can be disproportionate for simple graphics that could be vectorised as SVG or quantised to a palette. Selecting PNG should be an informed trade-off between exactness, transparency needs, and delivery budget.

Performance and file size considerations

PNG files are already compressed with DEFLATE, so transport compression (Gzip/Brotli) yields minimal gains and adds CPU overhead; most servers rightly exclude PNG from additional compression. The main performance levers are choosing the right colour mode (palette vs truecolour), optimising filters and DEFLATE parameters, removing unnecessary metadata, and avoiding interlacing unless early preview is essential. For display performance, smaller dimensions and fewer pixels often matter as much as codec choice.

Decode cost for PNG is moderate on modern devices, but large transparent images layered over content can create rendering overhead due to blending. On memory-constrained devices, high-resolution PNGs may increase raster memory footprint, impacting responsiveness. Where a site ships many small PNGs, HTTP/2 or HTTP/3 mitigates request overhead, yet consolidating assets or using SVG for simple icons can reduce total transfer and decode work further.

Responsively serving correct sizes (srcset/sizes) remains critical: sending a 2,000‑px PNG to a 360‑px viewport wastes bandwidth regardless of format. Caching helps, but the first contentful delivery—especially for hero graphics—benefits most from byte reduction. Preloading a critical PNG can stabilise layout and improve visual readiness, yet format and size choices often determine the largest gains for loading metrics.

File size and Core Web Vitals

Images are frequently the Largest Contentful Paint (LCP) element, so heavy PNGs can delay meaningful rendering and harm performance signals. Because PNG is lossless, its files for photographic content tend to be significantly larger than modern lossy alternatives. Right-sizing and format selection for hero and above-the-fold assets has an outsized impact on LCP, especially on mobile connections where transfer time dominates.

For similar visual quality on line art and UI, lossless WebP often yields files about a quarter smaller than PNG (commonly around 26% reduction), improving transfer efficiency. For photographic images, lossy WebP and AVIF can be substantially smaller than PNG while retaining acceptable visual quality for the web, which can reduce LCP by cutting bytes and decode time. Gains scale with image prominence and pixel count, so prioritising the largest elements yields the best returns.

Field outcomes vary by content, encoding settings, and device, but a pipeline that falls back to PNG only when transparency or exactness is essential tends to achieve better Core Web Vitals. Combining modern formats with responsive images, caching, and CDN delivery can further stabilise LCP, CLS, and INP by reducing payloads and CPU work across diverse networks and hardware profiles.

Overview of viable alternatives to PNG

Several formats complement or replace PNG depending on content and constraints. Selecting among them hinges on the need for losslessness, transparency, vector scalability, and support targets. A mixed strategy—serving modern formats with PNG fallback—often balances performance and compatibility while preserving visual intent for critical brand assets.

• WebP (lossless): Typically smaller than PNG for UI/line art; supports alpha; broad browser support.
• WebP (lossy) and AVIF: Strong reductions for photos; both support transparency; AVIF often leads in compression efficiency at similar quality.
• SVG: Vector alternative for logos, icons, and simple illustrations; scales without pixelation and is usually much smaller for geometric graphics.
• JPEG/JPEG 2000/JPEG XR: Lossy options for photographs; generally smaller than PNG, but lack true alpha (except JPEG 2000/JXR in specific contexts and with limited support).

When animation is needed, APNG preserves PNG’s quality and transparency but can be large; animated WebP or video formats (e.g., MP4/AV1) are often more data-efficient. Production choices should align with support matrices and the visual tolerances of the brand and UI.

Implementation notes

Choose the smallest adequate colour mode: prefer indexed-colour (PNG‑8) for limited palettes and flat graphics, and reserve truecolour + alpha (PNG‑24/32) for gradients or complex transparency. Palette optimisation and colour quantisation (e.g., pngquant) can deliver large reductions with minimal visual change, especially for UI sprites and screenshots. Avoid Adam7 interlacing unless progressive rendering is essential, as it typically increases size and decode work.

Use robust encoders and optimisers that explore filter strategies and DEFLATE parameters (e.g., Oxipng, Zopfli-based tools). These tools test multiple filter combinations per row and apply slower, denser compression to squeeze out extra bytes. Strip non-critical metadata (e.g., unnecessary tEXt/iTXt, large ICC profiles) while retaining essential colour management where brand accuracy matters; misplaced gamma or colour profile data can lead to perceptual shifts in some display pipelines.

Integrate responsive delivery via srcset/sizes and serve immutable cache headers for static PNGs. Conditional delivery through the picture element can offer modern formats with PNG fallback for legacy clients. On the server side, skip additional Gzip/Brotli on PNG files, and prefer CDN edge caching with appropriate content-type and cache-control directives to minimise latency and origin load.

Comparisons

PNG vs WebP

Lossless WebP often produces files roughly a quarter smaller than PNG for similar line art and UI assets, with alpha support and wide browser coverage. PNG remains preferable for maximum compatibility with very old platforms and when exact legacy colour pipelines are required. For photos, lossy WebP typically outperforms PNG by a large margin in file size at acceptable visual quality.

PNG vs AVIF

AVIF offers excellent compression efficiency and supports alpha, making it attractive for transparent photographic assets and complex UI textures. However, encoding can be slower and older environments may lack support. PNG remains a safer fallback where predictability, tooling maturity, and compatibility are paramount, especially for small, simple graphics where PNG-8 may already be very compact.

PNG vs SVG

SVG is a vector format that scales without loss and is often dramatically smaller for logos, icons, and geometric illustrations. PNG is better for pixel-specific effects, complex raster shading, or when exact raster rendering is required across environments. A common approach is to keep brand marks in SVG and export PNG fallbacks only where raster is necessary (e.g., email clients or social sharing images).

PNG vs JPEG/GIF

JPEG is optimised for lossy photographic compression and is typically much smaller than PNG for photos but lacks true alpha. GIF is limited to 256 colours and is inefficient for animations compared with modern options. PNG outclasses GIF for still graphics in quality and compression, while JPEG excels for photos; animated requirements are often better met by animated WebP, AVIF sequences, or video.

FAQs

When should PNG be preferred over WebP or AVIF?

Use PNG when exact lossless output is required for brand-critical UI, when vector is not appropriate, or when targeting environments lacking reliable support for modern codecs. It is also a strong choice for small icons and line art that compress well as PNG‑8. For hero photos or large illustrations, modern formats usually deliver better performance outcomes.

What is the difference between PNG-8 and PNG-24 (PNG-32)?

PNG‑8 refers to indexed colour with up to 256 palette entries and optional 1‑bit or 8‑bit alpha (via tRNS or indexed alpha), offering small files for flat graphics. PNG‑24/32 are shorthand for truecolour (24‑bit RGB) plus optional 8‑bit alpha, preserving gradients and subtle shading at larger sizes. Choosing the smallest acceptable mode can significantly reduce payload without visual compromise in UI contexts.

Does PNG support animation natively?

Standard PNG does not, but APNG (Animated PNG) is a widely supported extension that adds animation while retaining 24‑bit colour and alpha. APNG files can be large compared with video or animated WebP/AVIF, so it is best used for short, lightweight UI animations or where transparency and precise colour are indispensable. For longer or photographic sequences, video formats are typically more efficient.

Should PNG files be Gzipped or Brotli-compressed over HTTP?

No. PNG is already DEFLATE-compressed, so additional transfer compression yields negligible savings and adds CPU overhead. Configure servers to exclude image formats such as PNG, JPEG, WebP, and AVIF from content-encoding while ensuring optimal caching and CDN delivery.

How can PNG file size be reduced without visible quality loss?

Quantise to indexed colour where feasible, disable interlacing, and use optimisers that test multiple filter strategies and high-effort DEFLATE (e.g., Oxipng, Zopfli, pngcrush). Remove redundant metadata and right-size dimensions for the target layout. For images with photographic content, switch to a modern format with PNG fallback to achieve the most significant byte savings.