JPG vs PNG vs WebP: Which Image Format Should You Use?

The short answer: use WebP for the web, JPG for universal compatibility, and PNG for transparency and sharp graphics. Pick the wrong one and you either serve files far larger than needed, lose a transparent background, or end up with an image that will not open where you need it. This guide explains the key differences, exactly when each format wins, and gives you a quick decision guide. For the wider question of what to serve on a site, see our best image format for websites guide.

What Are the Key Differences?

All three store images, but they compress differently and support different features (MDN Web Docs). JPG uses lossy compression, permanently discarding some data to keep photos small, and does not support transparency. PNG uses lossless compression, storing every pixel exactly, and supports transparency, which makes it ideal for graphics and text. WebP, developed by Google, does both lossy and lossless compression, supports transparency and animation, and produces the smallest files of the three.

The size difference is not marketing, and Google published the working. Their WebP compression study compared the two formats across roughly 11,000 images drawn from four sets, including the 24 Kodak photographs, 100 Tecnick test images and a large web crawl. WebP came out 25 to 34 percent smaller than JPEG at the same Structural Similarity index. That last detail matters more than the percentage. They measured against SSIM rather than PSNR because SSIM tracks perceived visual quality more closely, so this is a like-for-like comparison at matched quality rather than a smaller file that quietly looks worse.

PNG is worth being precise about too, because it is a formal standard rather than a convention. The PNG Third Edition specification became a W3C Recommendation on 24 June 2025. It defines PNG as lossless, portable, well-compressed storage for raster images, and it is explicit that the original data is reconstructed exactly, bit for bit. Alpha transparency is stored as 8-bit or 16-bit samples, which is why PNG edges stay clean against any background.

One thing that specification changed, and most format guides have not caught up with: PNG Third Edition covers animated raster images as well as static ones. If you have read that PNG cannot animate and you need GIF for that, this is now out of date.

WebP quietly got the same treatment, and this is the update most comparisons miss. For years the only definition of WebP was Google's own documentation plus the libwebp reference implementation, which is a fair reason to have treated it as a vendor format. That changed in November 2024, when Zern, Massimino and Alakuijala published RFC 9649 through the IETF. It defines the format properly, the RIFF container, the VP8 lossy path, the lossless transforms, transparency, animation, colour profiles and Exif or XMP metadata, and it registers the image/webp media type.

Be precise about what that does and does not mean, though. RFC 9649 is Informational, not an Internet Standards Track document. So it is a formal, citable specification rather than a mandate, and nothing about it obliges anyone to support WebP. What it does change is the honest answer to "is WebP just a Google thing." It was. It is now a documented format anyone can implement from the spec, which is most of why the browser support caught up.

Here is how the three compare at a glance:

Format	Best use case	File size (photo)	Transparency
JPG	Photos, universal sharing, email	Medium	No
PNG	Logos, icons, text, screenshots	Large	Yes
WebP	Web images (photos and graphics)	Smallest	Yes

One more distinction worth knowing is lossy versus lossless. Lossy formats (JPG and lossy WebP) trade a little quality for much smaller files and degrade slightly each time you re-save. Lossless formats (PNG and lossless WebP) keep every pixel, which is what you want for text and sharp edges.

Advertisement

When Should You Use JPG?

JPG is the safe, universal choice for photographs. Reach for it when:

• You are sharing photos that must open on any device or in any app, including older software.
• You are sending an email attachment, since most email clients do not render WebP reliably.
• You are uploading to a platform where you are unsure whether WebP is supported.
• You need a small photo file and the image does not require a transparent background.

The tradeoffs are that JPG cannot store transparency and that it loses a little quality each time it is saved, so text and sharp geometric shapes can look blocky at lower quality settings. For photos, though, JPG at around 80 to 85 percent quality looks excellent to most viewers. If your photos come from an iPhone as HEIC, our HEIC vs JPG guide explains when to convert.

When Should You Use PNG?

PNG is the format for precision. Because it is lossless and supports transparency, it is the right choice when:

• Your image needs a transparent background, such as a logo, icon, or product cutout.
• You are saving a screenshot or any image containing text, where sharpness matters.
• You are working with flat graphics, diagrams, or line art with hard edges.
• You will edit and re-save the file repeatedly and cannot accept cumulative quality loss.

The catch is file size. For a full-color photograph, PNG is much heavier than JPG or WebP, so it is the wrong choice for photos on a web page. Use PNG where crispness and transparency matter, not where you simply want a small photo. You can convert PNG to JPG in seconds when you need a smaller file and no transparency.

When Should You Use WebP?

WebP is the best all-round format for the modern web. Choose it when:

• You are serving images on a website and file size directly affects load speed and Core Web Vitals.
• Your audience is on current browsers, which is nearly everyone: WebP works in Chrome, Firefox, Edge, and Safari from version 14, covering roughly 97 percent of global users, per Can I Use.
• You want the smallest photo file without visible quality loss.
• You need transparency but want a lighter file than PNG.

The main limitation is compatibility at the edges: some older software and most email clients do not handle WebP. The standard fix is to serve WebP with a JPG or PNG fallback using the HTML picture element, so modern browsers get the small WebP and everything else gets a supported format. When you need a universally compatible copy, convert WebP to JPG for free.

Should You Be Using AVIF Instead?

Increasingly, yes, and any format guide that stops at WebP is a couple of years out of date.

AVIF is the newer contender, built on the AV1 video codec and royalty free. On compression it is not close. MDN puts lossy AVIF at around 50 percent smaller than JPEG, against WebP's roughly 30 percent on the same set of images. So AVIF is not a marginal gain over WebP. It is close to another halving.

It also does things neither of the others can. AVIF supports high dynamic range and a wider color gamut, alongside the transparency, animation and higher color depths you already get from WebP.

Two catches, and they are the reason this is not simply the new default.

The first is browser support. MDN lists AVIF arriving in Chrome 85, Firefox 93, Opera 71, Safari 16.1 and Edge 121. That covers current browsers, but it has little historical depth compared with JPG, so MDN's own advice is to serve a fallback in WebP, JPEG or PNG using the <picture> element rather than shipping AVIF alone.

The second is subtler and rarely mentioned. AVIF does not do progressive rendering. The file has to download fully before anything appears. WebP and JPG can paint something early, so on a slow connection an AVIF image shows nothing and then everything, while a JPG fades in. For a large hero image on mobile, that is a real perceived-speed difference even though the AVIF file is smaller.

The practical answer for most people: WebP remains the safe modern default because support is now universal across current Chrome, Edge, Firefox, Opera and Safari. Reach for AVIF when image weight genuinely matters and you are willing to set up the fallback markup. Both beat serving a plain JPG to everyone.

Does AVIF Take Longer to Make Than WebP?

Not as much as you have probably read. The "AVIF is far too slow to encode" objection gets repeated constantly, and it is mostly out of date. But there is a real version of the concern hiding underneath it, and it depends entirely on when the encoding happens.

Google's web.dev team addressed this directly in Deploying AVIF for more responsive websites. Their finding is that with a multi threaded encoding scheme, AVIF "achieves similar performance for common use cases while delivering significant compression gains." Older codecs like WebP do benefit from simpler algorithms, so they are less work to run. The gap just is not the chasm the folklore suggests once the encoder can use more than one core.

The same article draws a distinction that actually matters more than raw speed. AVIF is, in their words, "generally one of the fastest image encoders in terms of best quality and default effort, but is the slowest of all encoders for on-the-fly performance." Read that twice, because it flips the usual advice. If you are compressing images once and then serving the results, AVIF is competitive. If you are generating images on demand, in the request, while somebody waits, AVIF is the worst choice on the list.

So the question is not really which format encodes faster. It is whether encoding sits in your build step or in your response time.

If it is a build step, and for most sites it is, encoding cost barely matters. It happens once on your machine or your CI runner. Take the smaller files.

If it is on demand, generating thumbnails as people upload or resizing per request, use WebP and cache aggressively. The web.dev team notes that "compressing vast amounts of images at scale can be computationally expensive," and at genuine scale that stops being a technicality and starts being a hosting bill. Their suggested escape hatch is hardware acceleration, and the numbers there are striking: they cite an FPGA based encoder, Pulsar-AVIF, delivering a 7 to 23 times speed improvement over software avifenc at similar compression efficiency. Useful to know that ceiling exists, though almost nobody reading this needs an FPGA.

For anyone converting a handful of images by hand, none of this applies. You are waiting a second or two either way. It only becomes a decision when you are automating thousands of them, and our guide to batch resizing images covers how to structure that kind of job.

When Should You Use SVG Instead of Any of These?

For your logo, your icons, and anything drawn rather than photographed. This is the format most people forget exists, and for a whole category of images it beats every option above without being close.

The difference is fundamental. JPG, PNG and WebP are all raster formats: a fixed grid of pixels, so enlarging them means inventing detail that was never there. SVG isn't pixels at all. The W3C's Scalable Vector Graphics 2 specification describes it as an XML-based language for describing two-dimensional vector graphics, and the property that matters here is right in the name: SVG content is scalable to different display resolutions. The file stores instructions for drawing shapes, so the browser redraws it perfectly at any size.

What that buys you in practice:

• One file for every screen. No 1x, 2x and 3x versions of your logo. The same SVG is crisp on a phone and on a 5K monitor, which also kills a whole class of blurry-logo bug reports.
• Tiny files for simple shapes. A logo that costs 40KB as a PNG is often 2 to 5KB as an SVG, because you're storing a handful of paths instead of thousands of pixels.
• You can restyle it with CSS. The spec notes SVG is stylable and supports dynamic changes through script and declarative animation. So an icon can change colour on hover or in dark mode without you exporting a second file.
• The text inside stays real text. Which means it can be selected, searched and read by a screen reader, rather than being pixels that happen to look like letters.

Where SVG is the wrong answer is equally clear. Photographs. A photo has no shapes to describe, so converting one to SVG produces a file far larger than the JPG you started with, and it will look worse. The rule is simple: if a camera made it, use a raster format. If a designer drew it, use SVG.

Two practical cautions. An SVG is a text file that can contain script, so treat any SVG you did not create yourself the way you would treat any other untrusted file, and don't accept user-uploaded SVGs without sanitising them. And export sensibly from your design tool, because SVGs saved straight out of illustration software often carry editor metadata and thousands of unnecessary decimal places that bloat the file for no visual gain.

Should You Still Be Using GIF for Animation?

Almost never, and the replacement is a format already covered on this page.

GIF has two limits that nothing can work around. It caps out at 256 colours per frame, which is why gradients in a GIF look like contour lines and why video clips converted to GIF develop that grainy, dithered wash. And it compresses badly, so a few seconds of animation routinely runs to several megabytes.

WebP does the same job without either problem. RFC 9649, the IETF specification for the format, states that WebP supports lossless and lossy compression as well as alpha transparency and animation, with multiple frames and configurable pause durations between them. Full colour, real transparency, and dramatically smaller files. AVIF supports animation too and typically goes smaller still.

So the decision looks like this:

• Short looping animation on a website. Animated WebP, with the same picture element fallback pattern as the next section.
• Anything longer than a few seconds. Use actual video. An MP4 or WebM will be a fraction of the size of any animated image format, and it lets the viewer pause it.
• A reaction image for chat or social. Keep the GIF. Every platform accepts it, most of them re-encode it to video on their end anyway, and interoperability is the whole point in that context.

One accessibility note that outranks the file size question. Animation that starts automatically and runs for more than a few seconds needs a way to pause it. That applies whichever format you pick, and it's the reason a lot of decorative animated GIFs should simply be still images.

How Do You Serve WebP With a JPG Fallback?

Three times now this guide has told you to use a fallback. Here is the actual markup, because it is shorter than most people expect.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description here" width="1200" height="800">
</picture>

That is the whole thing. A modern browser takes the AVIF, a slightly older one takes the WebP, and anything that understands neither takes the JPG. Nobody sees a broken image.

The four rules that make it work

Order decides the winner. Per MDN, the browser walks the source elements in the order you wrote them and stops at the first one it can use. So list them smallest format first. Put the JPG source above the WebP and every browser will happily take the JPG, and you have gained nothing.

The img tag is not optional. The permitted content is zero or more source elements followed by exactly one img. It is doing two jobs: it is the last-resort fallback when nothing matches, and it is what actually describes the image to the page. Leave it out and you have no image at all.

Alt text and dimensions live on the img, not the picture. This is the mistake people make most. Putting alt on the picture element does nothing. Same for width and height, which is worth getting right because those two attributes are what let the browser reserve the space and avoid the layout jump as your image loads.

CSS targets the img too. If you are using object-fit or object-position to control cropping, apply them to the child img rather than the picture wrapper. MDN is explicit about that one.

One practical note on effort. You now need three copies of every image, which is fine if your CMS or build step generates them and tedious if you are doing it by hand. If you are hand-managing a small site, dropping the AVIF line and serving WebP with a JPG fallback gets you most of the benefit for two files instead of three. Our free image compressor handles making the smaller copies.

Does the Image Size Matter More Than the Format?

Usually, yes. And this is the thing most format guides never mention, including everything above this line.

Look again at what the picture element in the last section actually did. It switched the format. It did nothing about the dimensions. So a 2400 pixel wide hero image gets sent to a phone with a 400 pixel wide viewport, which downloads all 2400 pixels and then throws away six sevenths of them. Choosing WebP saved you 25 to 34 percent on that file. Sending the right size would have saved far more.

MDN's responsive images guide puts a number on it with their own example. A 480 pixel wide copy of their test photo is 63KB. The 800 pixel copy is 128KB. Serving the smaller one to a small screen saves 65KB, which is roughly half the weight of that image, from dimensions alone. That is a bigger saving than the format switch this whole article has been about.

How Do You Serve Different Sizes?

With srcset and sizes on the img tag. Same idea as the picture element, different axis.

<img
  srcset="photo-480w.jpg 480w, photo-800w.jpg 800w"
  sizes="(width <= 600px) 480px, 800px"
  src="photo-800w.jpg"
  alt="Description here">

The 480w is the file's real width in pixels, not a CSS size. The sizes attribute tells the browser how wide the image will actually be drawn on the page, which it cannot know before the CSS loads. That is the whole reason the attribute exists.

MDN spells out how the browser then decides. It looks at screen size, pixel density, zoom, orientation and network speed, finds the first media condition in your sizes list that is true, reads the slot width for that condition, and loads the matching image from srcset. If nothing matches exactly, it takes the first image bigger than the slot and scales it down.

Three things people get wrong:

• Slot widths take px or vw, not percentages. A value like 50vw works. 50% does not, and it will silently break your whole sizes list.
• Order matters, because the browser stops at the first match. Same rule as the source elements in the picture element above. Put your narrow conditions first.
• Keep the plain src. It is the fallback for anything that does not understand srcset, exactly like the img inside a picture element.

When Do You Use x Instead of w?

When the image is always drawn at the same size on the page and you only care about screen density. A logo in a fixed-width header is the classic case.

<img
  srcset="logo.png, logo-1.5x.png 1.5x, logo-2x.png 2x"
  src="logo.png"
  alt="Description here">

No sizes attribute here, and that is not an omission. With x descriptors the browser only needs the device pixel ratio to choose, so there is nothing for you to tell it. Simpler markup, narrower use case.

You can combine both approaches, since the source elements inside a picture also accept srcset and sizes. That gets you format switching and dimension switching at once, and it also gets you a lot of files to generate. Whether that is worth it depends on whether something is building them for you.

If you only take one action from this page, take this one: resize before you convert. A correctly sized JPG beats an oversized WebP, every time. Our image resizer handles the dimensions and the resizing guide covers what widths to target.

What Do These Formats Do With Your Photo's Metadata?

They all carry it in a separate container from the pixels, which is why converting a file can silently keep your GPS coordinates or silently throw away your colour profile. Neither outcome is announced.

Metadata here means EXIF, the block your camera or phone writes alongside the image. The W3C's PNG specification describes it as "exchangeable image file format metadata such as shutter speed, aperture, and orientation," stored in a dedicated eXIf chunk. On a phone photo it usually also includes the date, the device model, and often the exact location where you stood.

WebP works the same way. The IETF's WebP specification, RFC 9649, defines EXIF and XMP as optional chunks, noting there "SHOULD be at most one chunk of each type" and that readers may ignore any extras. JPG has carried EXIF the longest and is where most of it originates.

The word doing the work in all three specs is optional. Metadata isn't part of the image, it travels beside it, so whether it survives a conversion depends entirely on the tool you used. Two converters can produce visually identical files where one kept your home address and the other didn't.

Three things follow from that.

• Check before you publish photos taken on a phone. Especially anything shot at home, at a child's school, or anywhere you'd rather not pin on a map. Most social platforms strip EXIF on upload, but a file you email, attach, or host yourself keeps whatever it arrived with.
• Don't assume conversion strips it. Converting JPG to WebP does not automatically clean the file. The format supports the chunk, so a faithful converter will carry it across.
• Watch the colour profile too, in the other direction. RFC 9649 says that where no ICC profile chunk is present, "sRGB SHOULD be assumed." Lose the profile off a wide-gamut photo and it doesn't break, it just quietly renders duller than the original.

Is There a Size Limit That Rules WebP Out?

Yes, and it catches people converting scans and panoramas. RFC 9649 is specific: "The 14-bit precision for image width and height limits the maximum size of a WebP lossless image to 16384x16384 pixels." For extended-format files, the canvas width multiplied by the height must be at most 2 to the power of 32 minus 1.

Sixteen thousand pixels a side sounds enormous until you're dealing with a high-resolution flatbed scan, a stitched panorama, or a large-format print file. Cross that line and lossless WebP simply isn't available to you. PNG has no comparable ceiling, and its sample depths run from 1 to 16 bits per channel, which is the other reason it stays the right answer for archival and print work. Our image resolution guide covers how big your files actually need to be, and the image size checker will tell you what you're holding.

What Is the Quick Decision Guide?

When you are not sure, match the job to the format:

Need to switch formats? Our free tools convert between all three instantly and privately in your browser: PNG to JPG, JPG to PNG, and WebP to JPG. If the file is still too heavy after converting, the image compressor is the next step, and our guide on compressing without quality loss explains where to set the slider.

For a rundown of every common format including HEIC, see our complete image format guide. If your question is specifically about page speed rather than format choice, our guide to the best image format for websites covers the serving side.

What Else Do People Ask?

Which is better, PNG, JPG, or WebP?

There is no single winner; each is best for a different job. Use WebP for images on modern websites because it gives the smallest files, JPG for photos that need to open everywhere including email and older software, and PNG for logos, screenshots, text, and anything needing a transparent background.

Is WebP smaller than JPG and PNG?

Yes. Google's WebP compression study, run across roughly 11,000 images, found WebP lossy files 25 to 34 percent smaller than comparable JPEG at the same Structural Similarity index, and WebP lossless about 26 percent smaller than PNG. Matching on SSIM matters, because it means the saving is at equivalent perceived quality rather than a smaller file that looks worse.

Do all browsers support WebP in 2026?

Almost all. WebP is supported by all modern browsers including Chrome, Firefox, Edge, and Safari from version 14, reaching roughly 97 percent of global users. For the small remainder on very old software, serve a JPG or PNG fallback using the HTML picture element.

When should I use PNG instead of JPG?

Use PNG when your image needs a transparent background, or when it contains text, sharp edges, or flat graphics such as logos, icons, and screenshots. PNG is lossless so it keeps these crisp. For full-color photographs, PNG files are much larger than JPG, so use JPG or WebP there.

Can I convert between PNG, JPG, and WebP for free?

Yes. Free browser-based converters switch between all three formats instantly and privately, with no upload to a server. Convert PNG to JPG to shrink a photo, JPG to PNG for transparency or lossless editing, or WebP to JPG for wider compatibility.

Related Articles

• Best Image Format for Websites in 2026
• The Complete Image Format Guide
• How to Compress Images Without Losing Quality

Sources: Google Developers, WebP Compression Study, comparing WebP and JPEG across roughly 11,000 images from the Kodak, Tecnick, Lenna and web crawl sets, measured on the Structural Similarity index. W3C, Portable Network Graphics Specification Third Edition, published as a W3C Recommendation on 24 June 2025, on PNG being lossless bit for bit, its 8-bit and 16-bit alpha samples, and its coverage of animated raster images. IETF, RFC 9649, WebP Image Format, Zern J., Massimino P. and Alakuijala J., November 2024, Informational category, defining the RIFF container, lossy and lossless paths, and registering the image/webp media type. MDN Web Docs, image file type and format guide, and the picture element reference, on source ordering, the required img element, and where alt text and dimensions belong. MDN Web Docs, Responsive images guide, on srcset w and x descriptors, the sizes attribute, the browser's selection process, and the worked example where a 480 pixel copy is 63KB against 128KB for the 800 pixel copy. W3C, Scalable Vector Graphics (SVG) 2, Candidate Recommendation, on SVG as an XML-based vector language that is scalable to different display resolutions, stylable, and scriptable with declarative animation. Browser support figures via Can I Use. Specifications and support tables change, so check the current versions before relying on a detail.