JPG vs PNG vs WebP: Which Image Format Should You Use? (With Sample Files to Test)

A practical guide to choosing between JPG, PNG, and WebP, covering what each format is good at, where each one falls apart, and which to reach for in 2026.

JPG vs PNG vs WebP: Which Image Format Should You Use? (With Sample Files to Test)

Every developer, designer, and content person has had this moment. You finish an image, hit export, and then sit there staring at the format dropdown. JPG? PNG? WebP? Something else? The wrong choice means either a bloated page that takes forever to load, or a crisp logo that looks like it went through a blender.

The good news is that for 95% of real-world use on the web, you only need to understand three formats properly. This article breaks down exactly when to reach for each one, where each quietly falls apart, and gives you downloadable sample files so you can test every claim here in your own stack instead of taking anyone's word for it.

The short answer, before we get into the detail

If you just want the shortcut, here it is.

Use JPG for photographs and anything with smooth colour gradients, when you don't need transparency and file size matters more than perfect fidelity. Use PNG for logos, icons, screenshots, and anything that needs a transparent background or crisp edges. Use WebP as your default for everything on the modern web, because it does both jobs better and produces smaller files.

That is the whole decision, compressed into a paragraph. If you want to know why, and more importantly when those rules break down, read on.

JPG: the workhorse that built the web

JPG (also written as JPEG, same format, different spelling) is a lossy raster format. Lossy means it throws away image data when you save it, in a clever way designed around what the human eye actually notices and ignores. Raster means the image is built from a grid of pixels rather than from mathematical shapes.

It has been the internet's default photo format for roughly three decades, and the reason is simple. The compression is genuinely brilliant at preserving the things people notice (colour transitions, subtle shading, overall composition) while ruthlessly discarding the things they don't (minor detail variation between adjacent pixels, very high frequency noise).

When JPG is the right call

Reach for JPG when you're saving a photograph or any image with lots of smooth colour gradients and subtle shading. Holiday photos, product photography, landscape shots, portraits, food photography. All of this is JPG territory. The format was essentially designed around how these kinds of images are put together.

It's also the right choice when file size is a bigger deal than absolute pixel-perfect quality. A JPG of a photograph will often be five to ten times smaller than the same image saved as PNG, and the human eye genuinely cannot tell the difference at normal viewing distances.

Where JPG quietly fails

JPG falls apart the moment you introduce sharp edges or solid blocks of colour. Try saving a screenshot of some text as a JPG and zoom in. You'll see a mess of blurry halos and coloured fuzz around every letter. This is called ringing or blocking artefacting, and it happens because JPG's compression works in 8x8 pixel blocks that smooth out high-frequency detail. Photographs barely notice this. Screenshots of your database admin panel absolutely do.

JPG also has no concept of transparency at all. If you save a logo with a transparent background as JPG, it will come out with a solid white background. There is no workaround for this other than switching formats.

Finally, every time you edit and re-save a JPG, you lose a bit more quality. It compounds. If you save a JPG, open it, edit it, save it again, and repeat that cycle ten times, you'll see visible degradation by the end. For working files, always keep a lossless master copy and export to JPG only at the end.

If you want to see what JPG compression actually does to different kinds of source images, the JPG sample files page has test images at various resolutions that you can drop into your own pipeline.

PNG: the format for when edges matter

PNG is a lossless raster format with an alpha channel. Lossless means it never throws data away during compression, so what you put in is exactly what you get out. The alpha channel is the technical term for transparency, and it's why PNG has been the default format for logos, UI assets, and screenshots since the late 1990s.

When PNG is the right call

PNG is what you want any time you need transparency. Logos going on top of coloured backgrounds, product cutouts where you want no background at all, UI overlays, icons. Anything where you need the pixel values to be completely preserved, PNG handles it.

It's also the right pick for anything with sharp edges or text, which is really the same problem viewed from a different angle. Screenshots of your app, diagrams, technical illustrations, charts with thin lines. The lossless compression means every edge stays razor sharp, and the alpha channel means you can drop these assets onto any background.

Where PNG falls short

PNG's big weakness is photographs. If you save a photograph as PNG, you'll end up with a file that's often five to ten times larger than the equivalent JPG, for visual output that looks effectively identical. For a single hero image on a landing page this might not matter much. For a gallery of 50 photos it turns into a real performance problem.

PNG also doesn't handle animation (that's GIF territory, or better yet, short video), and it produces bigger files than WebP for almost every use case where both would work.

One practical thing worth mentioning: PNG supports different bit depths and colour modes. If you're generating PNGs server side you want to be sure your pipeline is producing 8-bit indexed PNGs for simple graphics and 24-bit PNGs with alpha for anything complex. Get this wrong and file sizes can balloon for no visible reason.

The PNG sample files collection includes images with transparency specifically so you can verify your rendering pipeline handles the alpha channel correctly. It's a surprisingly common breakage point when images get processed by server-side tools or CMS plugins.

WebP: the format that quietly replaced both

WebP is Google's image format. It launched in 2010 and had a slow decade waiting for browser support to catch up, but in 2026 it works in every major browser, every major CMS, and most image editing software. If you've been ignoring it, now is the time to stop.

Here's what makes WebP genuinely different. It offers both lossy and lossless compression (so it covers both JPG's and PNG's use cases), and it supports transparency in both modes. And the files are smaller. Typically 25 to 35% smaller than JPG for photographs, and up to 50% smaller than PNG for graphics with transparency. Same visual quality, smaller files. That's the whole pitch.

When WebP is the right call

Basically, whenever you're producing images for the modern web. If you'd reach for JPG, try WebP first. If you'd reach for PNG, try WebP first. For the vast majority of websites, WebP is now the sensible default, with JPG and PNG as fallbacks for specific cases.

It's especially worth using when you're serving images at scale. An e-commerce site with a thousand product photos sees real bandwidth and page load improvements from the switch. A personal portfolio with ten hero images, less so, but still a free win.

Where to be cautious with WebP

A few situations where WebP isn't the right call. If your images need to travel through legacy software, email clients, older versions of Office, or anywhere else outside the browser, WebP support gets patchy. For user uploaded content that might end up forwarded to third parties, JPG is still a safer bet.

The encoding is also slower than JPG. If you're generating thousands of images per second on the fly (imagine a social media platform resizing user uploads in real time), the extra CPU time is worth measuring. For most sites this is a non-issue, because you're encoding images once and serving them millions of times, but it's worth being aware of.

Finally, very old analytics and image processing tools sometimes don't understand WebP yet. This is a shrinking problem but not a zero problem.

You can see how WebP compares file-size-wise against the same source image rendered as JPG and PNG by grabbing a few matching samples from the image files hub and running them through your own build.

A decision tree that actually works

Rather than memorising all of the above, you can get to the right answer with three questions asked in order.

First question. Does this image need transparency? If yes, you're choosing between PNG and WebP. Pick WebP unless you have a specific legacy reason not to.

Second question. Is this image a photograph or something with smooth gradients? If yes, pick WebP. Fall back to JPG if the file needs to survive a trip through older software.

Third question. Is this a screenshot, logo, icon, or diagram with sharp edges? If yes, pick WebP. Fall back to PNG if you need it.

You'll notice WebP wins almost every round. That isn't a mistake. It was designed explicitly to replace both JPG and PNG, and it largely succeeds.

The formats worth knowing about, but probably not using

A few honourable mentions that deserve a sentence or two.

SVG is a vector format, which means the image is stored as mathematical instructions rather than as a grid of pixels. It's the right choice for logos and icons that need to display cleanly at multiple sizes, because it scales infinitely without losing quality. SVG isn't really in competition with JPG, PNG, or WebP. It sits alongside them, filling a specific niche. Use it for your logo, your icon set, and your simple illustrations.

GIF is effectively obsolete for static images and increasingly obsolete for animation too. For static graphics, PNG and WebP beat it on every metric that matters. For animation, short MP4 or WebM video files produce dramatically smaller files and better quality. If you're reaching for GIF in 2026, reach for one of those instead. That said, the format isn't going anywhere, and if you need to test your pipeline with animated GIFs, there are sample GIF files available.

TIFF and BMP are archival and print formats. TIFF is common in professional photography, medical imaging, and publishing workflows because it supports lossless compression and various colour profiles. BMP is a Windows format from the old days, still used occasionally in Windows-specific software. Neither has any business being on the web. If you're working in a pipeline that touches either format, the image hub has sample files for TIFF and BMP you can test with.

Actually testing this yourself

Here's the thing about image format debates. Everyone has an opinion, everyone cites the same studies, and the correct answer for your specific use case can only really be settled by running your own images through your own pipeline and measuring.

The fastest way to do that is to grab a matching set of test images, all generated with consistent dimensions and content, and run each one through your build, your CDN, your image processing step, your CMS upload flow, whatever the relevant part of your stack is. Measure file size on disk, measure the rendered size served to the browser, measure the perceived quality when you zoom in, and check the edge cases (alpha channels, colour profiles, metadata stripping, automatic format conversion).

The full set of image sample files available are:

All of them are free, with no licensing attached, no login required, and no royalties to worry about. Drop them wherever you need to settle a format question.

The bottom line

The honest, practical answer to "which image format should I use" in 2026 is WebP, with a JPG or PNG fallback for the specific cases where compatibility demands it.

JPG still owns the legacy photography pipeline and anywhere images need to leave the browser ecosystem. PNG still owns the legacy transparency use case and workflows that haven't been updated in a few years. Both are fine choices when you need them. But for anything new you're building on the modern web, WebP is the sensible default, and the other two are the backup plan rather than the starting point.

The single most useful thing you can do today is stop picking image formats based on habit and start picking them based on what the image actually is and where it's going. The rules above cover 95% of cases. For the other 5%, download the sample files and test it yourself.

If you want more sample files across every format imaginable, not just images but documents, video, audio, code, and data files, the full library is free, royalty-free, and available without signing up for anything.