The 30-second rule
Photographs without transparency: WebP. Falls back to JPEG for older audiences.
Graphics, screenshots, anything with transparency: PNG. Or WebP-lossless for smaller files.
Animated content: WebP or animated PNG.
The picture element makes the fallback question almost free. Wrap a WebP source and a JPG source inside a picture tag and every browser picks the best one it understands. There's no JavaScript involved and no performance penalty for the unused source.
Real numbers
A representative 4 MB phone photo:
- JPEG quality 85: ~700 KB
- JPEG quality 70: ~400 KB
- WebP quality 80: ~250 KB
- PNG: ~3.5 MB
Browser support
WebP is supported in every major modern browser including Safari (since macOS Big Sur / iOS 14). Less than 0.5% of web traffic now lacks WebP support, so it's a safe default for new sites.
AVIF, the newer challenger, reaches roughly 95% of global traffic as of 2026. The remaining gap is mostly older corporate Windows installs running Edge Legacy or pinned Chrome builds. For sites where every kilobyte matters and you can tolerate slower encode times, AVIF is worth shipping as the first source in a picture element with WebP as the second fallback.
JPEG and PNG are universal. They will work in any browser made in the past 25 years. If you're shipping content for kiosks, embedded systems, or unusually old devices, default to those two and skip the format gymnastics.
Converting between formats
Use the freeimgtool format converter to switch between JPG, PNG, and WebP — transparency is preserved where the format supports it.
Converting JPG to PNG does not improve quality. The JPEG compression artifacts are baked into the pixels at that point; PNG just stores them losslessly at a larger size. The only time JPG-to-PNG makes sense is when you need transparency for further editing or you want to stop the file from degrading any further during repeated saves.
Converting PNG to JPG drops transparency entirely. The transparent regions get flattened against a background color (white by default). Watch out for this on logos and product cutouts — the visible result changes the moment you save as JPG.
Format internals: what each one actually does
JPEG uses the discrete cosine transform on 8x8 blocks and discards high-frequency coefficients based on a quality setting. It's tuned for photographic content where neighboring pixels vary smoothly. The format has no support for transparency, animation, or color depth beyond 8 bits per channel.
PNG uses DEFLATE compression (the same algorithm as gzip) over filtered scanlines. It's lossless and supports an alpha channel, 16-bit color depth, and indexed palettes. Because it's lossless, it cannot match JPEG on photographs — there's simply too much fine variation to compress away without throwing data out.
WebP has two modes. Lossy WebP uses VP8 intra-frame coding, which is closer to a modern video codec than to JPEG. It uses predictive coding across blocks, which lets it represent gradients and flat regions more efficiently than JPEG. Lossless WebP uses a custom entropy-coded format with color cache and transform predictors, beating PNG by 20-30% on typical screenshots and graphics.
AVIF is a still-image profile of the AV1 video codec. It uses 64x64 superblocks with recursive partitioning, which captures both fine detail and large flat regions far better than JPEG's fixed 8x8 grid. The cost is encode time — AVIF can be 5-20x slower to encode than WebP at comparable quality.
When to keep JPG instead of upgrading
Email attachments and downstream sharing. Many email clients, CMS systems, and chat apps still strip or misrender WebP. If the recipient might forward or edit the image, JPG is the safer wire format.
Existing CDN pipelines that already serve JPG at scale. The cost of migrating an entire image pipeline to WebP is rarely justified by the 20-30% file size win unless bandwidth is a real bottleneck. Compress JPGs aggressively with mozjpeg first; the gap to WebP narrows considerably.
User-uploaded content that needs predictable handling. JPG decode is universal, fast, and deterministic across every server-side library. WebP support in older Python, PHP, or Ruby image libraries can be patchy. For a user uploads pipeline, consume any format but normalize to JPG before storing.
Frequently asked questions
Does WebP work in Safari?
Yes — since macOS Big Sur and iOS 14, both released in 2020.
Should I always use WebP?
For new sites, yes. For maximum compatibility, serve WebP with a JPEG fallback via the picture element.
Is AVIF better than WebP?
Smaller files, slightly less browser support, slower encode. Worth it for high-traffic pages where every kilobyte matters.
What about SVG for the web?
SVG is the right answer for logos, icons, and anything geometric. It's not a competitor to JPG/PNG/WebP — it's for vector content, which renders crisp at any resolution and is typically smaller than a PNG of the same icon.
Does WebP support animation?
Yes. Animated WebP is supported in every modern browser and produces files roughly 30-50% smaller than equivalent animated GIFs, with full color support instead of GIF's 256-color limit.
Will my SEO suffer if I serve WebP?
No. Google indexes WebP images and uses them in image search. Page speed improvements from smaller WebP files actively help SEO.
What's the difference between WebP lossy and WebP lossless?
Lossy WebP discards visual information for smaller files (replaces JPEG). Lossless WebP stores every pixel exactly with no quality loss (replaces PNG). Most tools default to lossy; you have to explicitly request lossless mode.
Does using modern formats affect Core Web Vitals?
Yes. Smaller image files improve Largest Contentful Paint (LCP), which is one of the main Core Web Vitals metrics. Switching from JPG to WebP or AVIF on hero images typically improves LCP by 200-500 ms on slow connections.