PNG vs JPG vs WebP vs AVIF

PNG, JPG, WebP and AVIF compress the same pixels under different contracts. PNG is lossless and supports transparency; JPG is lossy, much smaller for photographs, and has no alpha. WebP and AVIF do both, each roughly a quarter smaller than the last. In 2026 all four decode natively in every major browser.

Nur lokal

Die folgende Anleitung ist nur auf Englisch verfügbar.

Every image file answers the same question — how do I store these pixels in fewer bytes? — with a different strategy. PNG refuses to lose information and compresses structure instead. JPG throws information away in an orderly, human-blind way and buys dramatic savings on photographs. WebP and AVIF are the modern generation, doing both jobs with better mathematics and, typically, smaller files.

The trade-offs are now almost entirely about content, not compatibility. WebP shipped in all major browsers in 2020 and AVIF followed by 2023-2024, so in 2026 the four formats decode natively everywhere that matters, including Safari. What decides the choice is what the image contains: hard edges or gradients, text or skin, a screenshot or a photograph, and whether transparency or a target file size is non-negotiable.

This guide compares the four formats on exactly those axes, explains why each compresses certain content badly, and covers the metadata that rides along in the container. Everything linked here — converter, compressor, resizer — runs locally in your browser, so testing a theory on your own file costs nothing and uploads nothing.

Once you have picked a format, the fastest way to act on it is the Image Converter which transcodes between PNG, JPG, WebP and AVIF right in the tab, no upload involved.

When the requirement is a hard size cap rather than a format, the walkthrough on compressing to a 100KB target shows how to walk the quality dial down to an exact target, checking quality by eye at each step.

Lossless versus lossy: the decision everything else follows

Lossless compression rearranges data so it reconstructs bit-for-bit identical pixels; lossy compression approximates the image, keeping what human vision is least likely to miss. Lossless is not smaller by definition — on a noisy photograph it can lose badly — and lossy is not ugly by definition. Each wins on the content it was designed for, which is why the first question is never which format is best but what the image contains.

Three content traits decide it. Photographs and soft gradients survive lossy compression gracefully; hard-edged graphics, text and screenshots punish it with ringing artefacts along every edge. Noise hurts any format, but it destroys lossless ratios, because noise is maximum information. And transparency is a hard requirement that immediately disqualifies JPG.

Format	Compression	Transparency	Typical best content
PNG	Lossless (DEFLATE)	Full alpha	Screenshots, UI, logos, line art
JPG	Lossy (DCT blocks)	None	Photographs, continuous tones
WebP	Lossy and lossless	Full alpha	Both roles; strong all-rounder
AVIF	Lossy and lossless	Full alpha	Photos at the smallest sizes; animation

PNG: exact pixels, alpha and metadata

PNG stores pixels losslessly: the decoder reproduces the original image exactly, every time, which is why it is the default for screenshots, design exports and anything containing text. It compresses by filtering each scanline against its neighbour and then applying general-purpose DEFLATE compression — the same family of mathematics as ZIP. That strategy loves repeated structure (flat colour, aligned UI, sharp borders) and it is why a clean app screenshot often compresses to a fraction of its raw size.

The same strategy is why PNG struggles on photographs: organic texture is close to random, filters cannot predict it, and the file balloons. PNG also carries full 8-bit alpha, so logos with soft edges over arbitrary backgrounds stay clean, and its container has room for rich metadata — including EXIF blocks — which matters again in the last section of this guide.

JPG: lossy, tiny for photos, allergic to edges

JPG divides the image into 8-by-8-pixel blocks, transforms each into frequency data (the discrete cosine transform), and discards the frequencies eyes are least sensitive to. The quality setting is the discard dial: at 80-90 a photograph looks essentially untouched at a fraction of the raw size, and below about 50 the blocks themselves become visible as the format's signature blocky artefacts.

Two consequences of the design matter in practice. First, no transparency, ever — the format has no alpha channel, and a file you want to knock out to transparent will arrive with a baked-in background. Second, hard edges suffer: a 1-pixel UI border or small text spreads its energy across several 8×8 blocks, and the reconstruction smears it into mosquito noise and ghosting. Chroma subsampling (averaging colour detail at half resolution) adds further softness on red-and-blue text. Keep JPG for what it was built for: continuous-tone photographs.

WebP and AVIF: the modern pair

WebP, from Google, does both jobs: a lossy mode based on the same predictive coding ideas as video compression (VP8), and a separate lossless mode that usually beats PNG by around a quarter. Its lossy photographs land roughly 25-35% smaller than JPG at comparable visual quality, and unlike JPG it supports alpha in both modes — so a photographic image with real transparency finally fits in a small file.

AVIF, built on the AV1 video codec, is the current frontier: intra-frame coding plus richer prediction tools make it roughly 20% smaller than WebP on typical content, with markedly better handling of gradients that band in other formats, and it supports 8-bit and higher depths, animation and alpha. The costs are real, though: encoding is dramatically slower (seconds instead of milliseconds at high effort), and tooling support is thinner. It is the format to choose when bytes are the binding constraint and encode time is not.

Against JPG at similar quality	Typical saving	Caveat
WebP (lossy)	≈ 25-35% smaller	Lossless mode is a separate codec, compares to PNG instead
AVIF (lossy)	≈ 20% smaller than WebP	Much slower encoding; thinner tool support
WebP (lossless)	≈ 25% smaller than PNG	Still loses to PNG nowhere — same lossless guarantee

Browser support in 2026

The compatibility question is settled. WebP has been universal since Safari 14 shipped it in 2020; AVIF landed in Chrome 85 and Firefox 93 in 2020-2021 and in Safari 16.4 in 2023, giving full evergreen coverage through 2024-2025 releases. Animated WebP and animated AVIF both decode everywhere current as well.

The residual caveats are at the margins, not the mainstream: very old Safari versions (iOS 13 and earlier) lack WebP, some AVIF files using exotic high-bit-depth or 12-bit profiles decode in fewer engines, and AVIF support in non-browser software — OS previews, older design tools, CMS pipelines — still lags its browser support. Serving AVIF with a WebP or JPG fallback via the picture element remains the defensive pattern for anything user-supplied.

Format	Shipped everywhere since	Still worth a fallback for
PNG, JPG	The 1990s	Never — truly universal
WebP	2020 (Safari 14 was the last holdout)	iOS 13 and earlier, legacy embeds
AVIF	2023 (Safari 16.4 was the last major engine)	Older Safari, non-browser viewers, CMS pipelines

EXIF: metadata lives in the container, not the pixels

An image file is two things: pixel data, and a container around it that can carry metadata — EXIF blocks recording camera model, exposure, orientation, timestamps and often GPS coordinates. A critical property follows: metadata belongs to the file, not the picture. Copy a JPG and the EXIF travels with it; re-encode the same photo to WebP or AVIF and the new container starts empty unless a tool deliberately copies the old metadata across.

That has two practical faces. Privacy: a photo shared straight from the camera can publish your location, which is why stripping metadata is a feature of any converter worth using — re-encoding is the reliable strip. Workflow: orientation and timestamps can be useful, so if a pipeline needs them, the tool must be told to preserve EXIF rather than assumed to. Either way, the decision lives in the container, and conversion is where it is made.

Frequently asked questions

Are my images uploaded when I compress or convert them here?

No. Decoding, re-encoding and resizing all run in your browser using its own image codecs; the file never leaves the tab. Confirm it in DevTools: open the Network panel, convert an image, and watch the request list stay empty. The site's Content-Security-Policy also forbids outbound connections from page scripts.

Which format should screenshots and UI captures use?

PNG, or WebP in lossless mode if size matters. Screenshots are full of hard edges, text and flat fills — content lossless compression crushes and lossy smears. A JPG screenshot shows ringing around every glyph and button border; the PNG of the same capture is usually smaller anyway, because its content is highly predictable.

Why is my PNG bigger than the JPG of the same photo?

Because photographs are almost random to a lossless codec. PNG must reconstruct every pixel exactly, and organic texture, sensor noise and grain defeat its predictors, so it stores nearly everything at high cost. JPG discards the imperceptible parts instead. The same photo can easily be five to ten times larger as PNG than as a good JPG or WebP.

Does converting an image strip its EXIF data?

Re-encoding to a different format starts a new container, so EXIF does not survive by default — which conveniently strips GPS and camera data. Within the same format, some tools copy metadata across, so stripping is never guaranteed by accident. If privacy matters, convert once and check the result's properties; if orientation matters, make sure the tool preserves or bakes it in.

Is AVIF always smaller than WebP?

No — on average roughly 20% smaller at similar quality, but the spread is wide. AVIF pulls furthest ahead on photographs and gradients; simple flat graphics can compress to nearly identical sizes, and a handful of images even reverse the ranking. Encode time is the other cost: AVIF at high effort takes orders of magnitude longer, which matters in build pipelines.

What quality setting should I use for lossy images?

For photographs, start around 75-85: below that, blocking and blurring appear quickly; above about 90, you pay real bytes for differences eyes cannot see. Graphics with text and edges tolerate lossy compression poorly at any setting, so prefer lossless there. Judge by eye on your own content at 100% zoom — settings interact with resolution and content, not just each other.

ToolsByUs team · How we check our tools