Image Formats Explained: PNG, JPG, WebP, AVIF — When to Use What

10 min read

Every CMS, every blog post about image optimization, every "speed your site up" video tells you to "use the right format." Almost none of them tell you which one that is, or why. So you end up with a folder full of PNGs that should have been JPGs, a hero banner that's 4 MB because nobody resized it, and a vague suspicion that WebP is "better" without knowing when. This guide is the version I wish I'd read five years ago. No format is universally best — each one wins in a specific situation, and gets in the way in others.

What actually makes an image file big

Before formats, three numbers determine how much disk space an image eats:

  • Pixel dimensions. A 4000×3000 photo has 16× the data of the same photo at 1000×750. Format choice cannot rescue you from shipping a 4000-pixel image into a 600-pixel slot — you're just throwing bytes at the user's CPU.
  • Bit depth and channels. An 8-bit RGB pixel is 3 bytes; an 8-bit RGBA pixel (with alpha transparency) is 4. A 16-bit-per-channel image doubles that. Most photos are 8-bit RGB, which is fine.
  • Compression. This is where format finally matters. Two images with identical pixels can be 5 MB or 200 KB depending on which codec encoded them and at what quality.

The cheapest size win is almost always step 1: resize before you compress. A 600-pixel-wide thumbnail saved as a perfectly-tuned AVIF will still beat a 4000-pixel JPEG. If you have not yet sized the image to its actual display dimensions, do that first with a tool like our image resizer before reaching for format conversion.

The four formats that matter today

There are dozens of image formats. In 2026 you only need to understand four of them well: PNG, JPG, WebP, and AVIF. GIF and SVG also come up but for narrow reasons covered at the end.

PNG — lossless, alpha-channel friendly, big

PNG is a lossless format. Every pixel you put in comes back out identical, forever, no matter how many times you re-save the file. It supports a full alpha channel (real transparency, not just one "transparent" color), and it's the only mainstream format every single image tool and browser has handled flawlessly since the 90s.

That reliability has a cost: PNGs of photographs are catastrophically large. A 1200×800 photo can be 3 MB as PNG and 180 KB as JPG with no visible difference. PNG is good at long runs of identical pixels (logos, icons, screenshots of UI, line art) and terrible at the noisy detail of real-world photography.

Use PNG for: logos with transparency, UI screenshots, diagrams, anything where you need exact pixels or text to stay sharp. Don't use PNG for: photographs — it'll bloat your page weight for zero quality win.

JPG — the ancient workhorse for photos

JPG (or JPEG, same thing) is from 1992 and still does one job better than almost anything else: compressing photographs. Its lossy compression discards visual detail you can't easily see — subtle color shifts in shadows, high-frequency noise in skin tones — and the result, at 75–85% quality, is usually indistinguishable from the original at normal viewing distance, at a fraction of the size.

JPG has no alpha channel. It cannot do transparency. Trying to export a logo with a transparent background as JPG gives you white-background-on-everything, which is the wrong answer every time. JPG also degrades each time you re-save it; the artifacts compound. Edit in PNG or the original RAW, export to JPG once at the end.

Use JPG for: photographs, complex gradients, anything where you can tolerate "perceptually identical" instead of "byte identical." Don't use JPG for: logos, icons, screenshots of text, anything with transparency.

WebP — the safe modern default

WebP was published by Google in 2010 and is supported by every major browser since around 2020. It's a single format that handles both lossless and lossy compression, supports alpha transparency, and consistently beats both PNG and JPG on file size at the same visual quality. For photographs WebP at quality 80 is typically 25–35% smaller than equivalent JPG. For PNG-style content (logos, UI), lossless WebP is typically 20–30% smaller than PNG.

The "consistently" matters. WebP doesn't have a magic edge case where it crushes the competition — it's just steadily better across the board. That makes it a great default when you're not optimizing per-image.

Catch: a small number of legacy environments (very old email clients, some image-editing software, certain CMS export pipelines) still don't accept WebP. For a website it's safe. For a file you're emailing to a non-technical client, send JPG or PNG.

Use WebP for: almost any web image when you control the surface. Don't use WebP for: deliverables to systems that may not accept it, or attachments in business email.

AVIF — the new champion, with caveats

AVIF (2019, based on the AV1 video codec) is the newest format on this list. At equal visual quality it produces files 30–50% smaller than WebP, which itself was already smaller than JPG. Browser support is now universal in evergreen browsers.

Two caveats. First, AVIF encoding is slow — meaningfully slower than JPG or WebP. For a one-off hero image it doesn't matter; for a batch of 5000 product photos it does. Second, encoder quality varies a lot: a poorly-tuned AVIF encoder can produce weirdly blocky artifacts in flat areas (skies, soft gradients) that are absent from a comparable WebP. Use a known-good encoder and check the output.

Use AVIF for: performance-critical pages, bandwidth-sensitive contexts (mobile, emerging markets), images you serve once and cache aggressively. Don't use AVIF for: images you need to edit further, deliverables to systems that don't accept it (most of email, older design tooling).

The two honorable mentions: GIF and SVG

GIF is mostly dead. It only encodes 256 colors, produces enormous files for anything photographic, and the one thing it does well (short animations) is now done better by short MP4/WebM video, by animated WebP, and by animated AVIF. The exception: tiny pixel-art animations and certain meme contexts where "GIF" is culturally the file you want.

SVG isn't a raster format at all — it's a vector format. SVGs describe shapes, paths, and text mathematically, so they scale to any size without losing sharpness, and they're often tiny (a few KB). Use SVG for any logo, icon, or illustration you have as vectors. Don't try to use SVG for photographs; it's the wrong tool.

Decision tree: which format, right now

Walk down. The first match is your answer.

  1. Is it a logo, icon, or illustration you have as vectors? → SVG.
  2. Is it a screenshot of UI or text where pixel sharpness matters, and the file is small (under a few hundred KB)? → PNG (or lossless WebP if you control the environment).
  3. Is it a photograph, and you're optimizing for a modern website? → AVIF first, WebP as fallback, JPG as final fallback.
  4. Is it a photograph being emailed, attached to a document, or sent to a client? → JPG at quality 85.
  5. Does it need transparency on a non-web surface (editing app, presentation slides)? → PNG.
  6. Is it an animation? → Short MP4/WebM video for anything modern, animated WebP for in-page UI, GIF only when culturally expected.

For most real workflows the answer is: PNG for graphics with transparency, JPG or WebP for photos, AVIF when you really need the bandwidth win. Stop agonizing over the edge cases.

Workflows that actually save bytes

Format choice is one step in a sequence. Skipping the other steps is the most common reason "I converted everything to WebP and the site is still slow." Here are the workflows that move the needle.

Resize first, then compress, then convert

This is the order that matters. If your image is 4000 pixels wide and your layout shows it at 1200 pixels, every conversion you do first wastes work — you're encoding 11 megapixels of detail that the browser is then going to throw away. Drop the dimensions first with our image resizer, then use image compressor to squeeze the bytes, then image converter if you also need to change format.

Crop before you compress

If the subject of the image is 40% of the frame and the rest is sky, you can lose 60% of the pixels with no quality cost by cropping. Our image cropper is the fastest way; do this before format conversion, not after. The same logic applies to letterboxed screenshots and screen recordings.

Match quality to display context

A hero banner on a marketing page deserves quality 85+. A thumbnail in a comment thread can survive at quality 65. People will not notice the difference on a 200-pixel thumbnail, and the page load saved is real. Most online compressors give you a quality slider — use it deliberately, not as "max means best."

Bundle photos into a single PDF when you can

If you're sending a collection of images to someone (a contract scan, a product gallery, a holiday album), a single PDF is often smaller than the sum of its parts and far more pleasant to read. Our image-to-PDF converter bundles them client-side. Just be aware: the PDF inherits the dimensions of the input images, so resize and crop first.

Mistakes that ship 4 MB images

"Saving as PNG to keep quality" on a photograph

The most expensive mistake. PNG is lossless, which sounds like the safe choice. For a photograph it produces a file 10× the size of the equivalent JPG at quality 85, with zero visible improvement. Lossless does not mean "high quality" — it means "exact pixels." Photographs do not benefit from exact pixels, because the human eye can't see the difference.

Re-saving JPGs repeatedly

Every JPG save adds compression artifacts. Open, edit, save, open, edit, save, and after three rounds the image looks visibly worse. Edit at the highest fidelity your source allows (RAW, PNG, the original WebP/AVIF), and export to JPG once when you're done.

Using WebP for the "I'll email this to grandma" file

Browser support is universal. Email clients are not browsers. Some older mail apps still don't render WebP attachments, and the recipient sees a broken image or a download they can't open. For email and similar legacy surfaces, JPG and PNG are still the safe defaults.

Trusting "auto" format conversion blindly

Many CMS platforms now ship images as "whatever the browser accepts." This is usually correct, but it can also re-encode an already-compressed JPG into a WebP, adding a second round of lossy compression on top of the first. Check your platform's defaults; sometimes "just upload the JPG" is correct and the platform should leave it alone.

Treating quality 100 as "the safe choice"

Quality 100 on lossy formats (JPG, WebP, AVIF) is usually wasteful. The size difference between quality 90 and quality 100 is large; the visual difference is almost nothing. For most photographic content, quality 80–85 is the sweet spot.

Privacy: why browser-based conversion matters

Most online image converters upload your file to a server, run ImageMagick or a similar pipeline, and send the result back. For a public marketing photo that's fine. For a screenshot of a private chat, a scanned ID document, a photo of a medical report, an unreleased product render — it's not.

Server-side converters keep your file in their pipeline for at least a few minutes (often longer for caching). Their privacy policy might claim immediate deletion. You have no way to verify that. If the same site offers free unlimited conversions, ask yourself what they're being paid in.

Client-side converters do the entire job in your browser tab using WebAssembly or the native Canvas API. The file is read into memory, processed locally, and written back to a download. Open DevTools, switch to the Network panel, and you'll see no upload happen. Every tool on easytoolapp — the image converter, compressor, resizer, and cropper — works this way. For anything you wouldn't post publicly, this is the only defensible choice.

What "lossless" actually means for images

Lossless is one of the most abused words in image tooling. Be precise about which one you mean.

  • Mathematically lossless — every output pixel equals every input pixel. PNG and lossless WebP do this. Lossless AVIF also exists but is rarely used.
  • Visually lossless — the result looks identical at normal viewing distance, but the underlying bytes are different. JPG at quality 90–95, WebP at 90, AVIF at 80, all qualify for typical photography.
  • "Lossless in this workflow" — marketing language. Usually means the tool didn't introduce additional compression on top of what was already there. Read the fine print.

For graphics with sharp edges and large flat areas (logos, UI), mathematical losslessness matters because lossy compression smears those edges into faint halos. For photographs it almost never matters; visually lossless at a fraction of the size is the better trade.

The honest bottom line

Resize first. Crop if you can. Pick the format that matches the content type, not the format you've always used. For photographs on the web: AVIF if you can, WebP otherwise, JPG as fallback. For graphics with transparency: PNG, or SVG if it's vector artwork. Quality 80–85 is almost always enough; quality 100 is almost always wasteful. And if the image contains anything you wouldn't post publicly, do the conversion in your browser, not on someone else's server.

If you want to put this into practice without uploading anything: our image converter handles format swaps, image compressor squeezes file size, image resizer drops dimensions, and image cropper trims the frame — all entirely in your browser, no uploads, no accounts.