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 96 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.

Why Does Red Text Look Fuzzy in JPG and WebP?

Because both formats throw away colour detail on purpose, and they do it before you touch the quality slider. Save a screenshot with red text as a JPG and the letters pick up a soft magenta halo that no amount of sharpening brings back. That's not your export settings. It's the format working as designed.

Here's the mechanism. Neither format stores your pixels as red, green and blue. They convert to a brightness channel plus two colour channels first. RFC 9649, the WebP specification, says lossy compression is achieved using VP8 intra-frame encoding, and that the VP8 spec "describes how to decode the image into Y'CbCr format," with Recommendation 601 used to get back to RGB.

Y' is brightness. Cb and Cr are the colour. And they are not stored at the same resolution. MDN puts the WebP case plainly: lossy WebP stores the image in 8-bit Y'CbCr 4:2:0 format. Most JPG encoders default to the same arrangement.

What 4:2:0 means in practice is that colour gets sampled at half resolution both horizontally and vertically. So you keep every brightness value and roughly a quarter of the colour values. The reason this is a reasonable trade is that human vision is far more sensitive to detail in brightness than detail in colour, so on a photograph of a face or a beach you genuinely cannot see the loss.

Then you point it at a hard edge between two saturated colours, and the whole assumption falls apart. Red text on white is the worst case anyone hits regularly, which is why it's the fastest way to test this. Thin coloured lines, logo edges, chart keys and UI screenshots all suffer the same way. The brightness edge stays crisp while the colour edge is being reconstructed from a quarter of the data, so the colour bleeds a pixel or two past where it should stop.

PNG doesn't do any of this. It keeps a full colour value for every pixel, which is the real reason it stays sharp on text and graphics rather than just because it's lossless in the abstract. MDN's own advice lines up: prefer PNG "when more precise reproduction of the image is required," and for screenshots, "unless you're willing to compromise on quality, you should use a lossless format."

So the working rules:

• Anything containing text goes to PNG or lossless WebP. Screenshots, UI mockups, diagrams, logos, charts with coloured labels. This single rule prevents most of the fuzzy-edge complaints people blame on compression quality.
• Photographs are fine in JPG or lossy WebP. The subsampling that ruins a logo is invisible on a photo, and that's the whole point of the trade.
• Raising quality only partly helps. Pushing a JPG to quality 95 reduces other artefacts but many encoders still subsample colour, so the fringe survives. Turning subsampling off, often labelled 4:4:4, is the setting that actually fixes it where your tool offers one.
• Lossless WebP sidesteps it entirely. It's a different code path from the lossy VP8 one, so you get PNG-style fidelity with smaller files, which is often the best answer for a screenshot on a web page.
• Test with the nastiest thing you have. Red or magenta text on a white background. If that survives, everything else will.

And this is worth knowing before the decision guide further down, because it explains why the answer isn't simply whichever format is smallest. Two files can be the same size and only one of them keeps your logo readable.

Does Converting Between Formats Lose Quality?

It depends entirely on which direction you go, and the conversion people reach for most often is the one that helps least.

Start with the one that surprises everyone. Converting a JPG to PNG does not repair it. Whatever the JPEG encoder threw away is gone from the pixels themselves, so the halos around text and the blotches in flat sky are now simply what the image is. PNG then does its job perfectly and stores that damage exactly, because the PNG specification reconstructs the original data bit for bit. You get a bigger file containing the same flaws. The only good reasons to make that conversion are that you need transparency added later, or you want a lossless working copy you can edit repeatedly without the damage compounding.

Going the other way is a real decision. PNG to JPG, or PNG to lossy WebP, is a one-way door. You will save a lot of space on a photograph and you will not get the original back, so keep the PNG if the image is a master rather than a final export.

What happens when you convert a JPG to WebP?

You are stacking one lossy codec on top of another, and they do not work the same way. RFC 9649 specifies that WebP achieves lossy compression using VP8 intra-frame encoding, which is a different algorithm from the one JPEG uses. So the encoder isn't tidying up the existing artifacts. It's approximating an image that was already an approximation, and re-approximating it with a different set of rules.

In practice the result is usually fine, because the second pass is working from something the first pass already smoothed. But there's a trap in the settings, and Google documents it in the WebP FAQ. Feed a JPEG saved at quality 80 into a WebP encoder set to quality 95 and you can end up with a bigger file than you started with. The encoder is faithfully preserving detail that isn't really there, including the artifacts. Google's advice is blunt about why this is hard to avoid: "Assessing the source's quality is often impossible, so it is advised to lower the target WebP quality if the file size is consistently larger."

That's the practical rule. When you convert an already-compressed file, set the target quality lower than feels comfortable, then check the output size. If it grew, your setting is too high.

Which conversions are actually safe?

Two, and they're the ones between lossless formats. PNG to lossless WebP and back again preserves everything, because RFC 9649 specifies that the WebP lossless algorithm "stores and restores the pixel values exactly, including the color values for fully transparent pixels." That last clause matters more than it sounds. Some tools discard the colour data hiding under fully transparent pixels, which is invisible until someone rescales the image and a halo of grey appears at the edges.

Everything else involving a lossy format costs you something, even when you cannot see it on the first pass. The cost is cumulative, so the thing to avoid is chaining: a JPG that became a WebP that became another JPG has been through three encoders and looks it.

The habit that solves all of this is keeping one lossless master, PNG or your editor's own format, and exporting every delivery copy from that master rather than from the last file you made. Our free PNG to JPG, JPG to PNG and WebP to JPG converters all run in your browser, so nothing gets uploaded, but they can't undo a lossy step that already happened. For choosing where to put the quality slider in the first place, our guide to compressing images without visible quality loss covers the settings.

Is AVIF Worth Using 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.

Worth putting a number on that, because the gap is smaller than the reputation suggests. Can I Use currently puts global AVIF support at 94.67 percent, against 96.18 percent for WebP. That is a gap of about one and a half percentage points, not the chasm people still talk about. The remaining holdouts are mostly Opera Mini, older KaiOS and QQ browsers, and Safari before 16.1. Those figures move, so check the current tables rather than quoting these back in six months.

So if you have been avoiding AVIF purely on support grounds, that argument has largely expired. The reasons to stay careful with it are the ones either side of this: the fallback markup you need to write anyway, the encode time covered in the next section, and the rendering behaviour below.

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.

What About JPEG XL?

Don't publish it as your only format yet. But the answer to this question changed recently enough that if you last looked in 2023 and concluded the format was dead, you were right at the time and you're wrong now.

JPEG XL is the fourth contender and on paper it's the strongest. The original Chromium Intent to Prototype, posted in March 2021, describes it as a royalty-free codec giving "about ~60% size savings when compared to original JPEG at the same perceptual quality," while supporting HDR, animation, an alpha channel, lossless JPEG recompression, and both lossless and progressive modes. Note that it beats AVIF on the one thing AVIF can't do, which is progressive rendering.

Then the politics. Chrome removed JPEG XL in 2022 and declared it obsolete, which is where most people's knowledge stops. Safari added it in 2023 and has supported it since, though incompletely, without animation or progressive decoding.

What changed is a reversal, and it is on the record now rather than in the rumour mill. On 24 August 2026 the Chromium team posted an Intent to Ship for JPEG XL decoding in Blink, built on jxl-rs, which the thread describes as a memory-safe pure Rust decoder. The Rust part is the whole argument. This is code that parses files sent by strangers, and the memory safety of the old C++ decoder was the objection that killed it the first time. The thread carries approvals from several project leads, records web developer sentiment as strongly positive, and names Cloudinary and Shopify among the parties that want to deploy the format.

Firefox is a step behind that. Mozilla posted its own Intent to prototype on 26 January 2026, also in Rust, behind a preference called image.jxl.enabled, and was openly exploratory about it rather than committing to anything.

Read both of those carefully before you act on them, because an Intent to Ship is not a ship. The Chromium thread lists no estimated milestone, so nobody has said which Chrome version this lands in or when it stops being something you have to switch on yourself. Approved and scheduled are different things, and only one of them changes what your visitors can open.

Here's the part that decides it for you regardless. Safari is the only browser that ships it switched on, and even there Can I Use records it as partial from version 17.0 rather than complete. Everywhere else it sits behind a flag, and a flag a user has to find and flip is not deployment. So your real-world coverage is Safari and nothing else.

Put a number on that and the decision makes itself. Can I Use currently puts global JPEG XL support at 15.02 percent, against 96.18 percent for WebP and 94.67 percent for AVIF. That is not a gap you close with a fallback chain, it is a format most of your visitors cannot open. So the practical rule is unchanged: keep delivering JPG, WebP or AVIF, and don't write a JXL-only page.

Is There Any Reason to Use It Today?

One, and it has nothing to do with your website. That lossless JPEG recompression feature in the spec list above is genuinely unusual: you can re-encode an existing JPEG into JPEG XL, get a meaningfully smaller file, and later reconstruct the original JPEG bit for bit. Nothing is thrown away.

That makes it interesting for archives rather than for delivery. If you're sitting on a decade of photos as JPGs and want them smaller without a one-way quality decision, this is the only format on this page that offers that trade. Converting the same photos to WebP or AVIF is lossy and permanent, so the original is gone.

Two cautions if you go that way. You're betting on tool support existing when you want the files back, so keep the originals until browser support is real rather than flagged. And this is an archival choice, not a web one. The format you store in and the format you serve don't have to match, and for most people right now they shouldn't.

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.

Is GIF Still Worth Using 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.

Where Does Animated PNG Fit In?

There is a fourth answer to the animation question that the section above skipped, and it has been sitting in every browser you own for years. Animated PNG, usually written APNG, is exactly what it sounds like: a PNG that moves.

It stopped being an unofficial extension recently. The PNG Third Edition, a W3C Recommendation dated 24 June 2025 and the same spec this page cites for HDR, gives APNG its own section and describes it in plain terms as intended to replace the simple animated images that have traditionally used GIF. The thing people used unofficially for years is now in the standard.

Support is not the problem either, which surprises people. Per MDN, APNG runs in Chrome from version 59, Firefox from version 3, Safari from version 8 and Edge from version 12. Those are old version numbers. This is not a format you are waiting on.

And it has one property nothing else on this page can match. APNG is backwards compatible by design, so a decoder that does not handle the animation chunks ignores them and displays the static image instead. That means a still frame rather than a broken image icon, from a plain .png file, with no picture element and no fallback chain. Animated WebP and AVIF both need the wrapper described in the next section. APNG just works.

Be clear about where it loses, though, because it loses badly in one place. APNG is PNG underneath, so it inherits PNG's lossless approach. Point it at a few seconds of video-like footage and the file will be enormous next to animated WebP or AVIF. MDN puts it the same way, noting that AVIF and WebP perform better while APNG has the broader support.

So the split is about what is moving rather than how long it moves for. Flat colour interface animation with transparency, the loading spinners, progress indicators and small looping sequences MDN names as its ideal use, is where APNG earns its place and where its one-file simplicity is worth more than the last few kilobytes. Anything photographic still belongs in animated WebP with a fallback, and anything past a few seconds still belongs in a video file.

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.

Will Switching Formats Actually Make Your Page Faster?

Often, but not always, and the cases where it doesn't are worth knowing before you spend an afternoon converting everything. Format is one of several things between a visitor and your main image. Sometimes it's the slow part. Sometimes it isn't.

Start with why it matters at all. Google's page speed metric for "when did the main thing appear" is Largest Contentful Paint, or LCP. According to Google's web.dev guidance, a good LCP is 2.5 seconds or less, measured at the 75th percentile of page loads on mobile and desktop. And on most sites, that main thing is a picture. The HTTP Archive's 2024 Web Almanac found that 68 percent of mobile pages had an image as their LCP element. So the image you pick a format for is very often the one your speed score hangs on.

Which Formats Are Websites Really Using?

Mostly the old ones, still. The same Web Almanac chapter broke down every image its crawler found on mobile pages in 2024.

• JPEG was the most common at 32.4 percent, down from 40 percent in 2022. That eight-point drop was the biggest shift of any format.
• PNG sat at 28.4 percent, basically flat.
• GIF was 16.8 percent and actually grew slightly, which the authors called the most surprising result.
• WebP was 12 percent, up about three points and 34 percent in relative terms over two years.
• AVIF was still only 1.0 percent, but that was a 386 percent jump in two years.

Read that as an opportunity rather than a verdict. Most images on the web are still in formats that are bigger than they need to be. If your site is among them, switching is one of the cheaper speed wins available. It also means you don't need to worry that WebP is some niche choice. It's already on more than one in ten images.

Why Might a Smaller File Not Make the Page Faster?

Because download time is only one part of LCP. Google's guide to optimising LCP gives an example that catches people out. If the main image is hidden until a script finishes loading, making the file smaller or switching to AVIF or WebP just moves the waiting from "downloading" to "waiting to be shown." The total doesn't change. The format was never the bottleneck.

So check these before you blame the format:

• Is your main image lazy-loaded? Google's guidance is blunt: never lazy-load your LCP image. Yet the Web Almanac found 9.5 percent of LCP images on mobile had loading="lazy" on them. Lazy loading is great for images further down the page. On the hero image, it tells the browser to wait.
• Can the browser find it early? An image set as a CSS background or injected by JavaScript is discovered late. A plain <img> in the HTML, or a preload with fetchpriority="high", lets it start downloading straight away.
• Is it the right size? As the section above covers, a 4000 pixel photo shown at 800 pixels wastes far more bytes than the difference between JPG and WebP. Resize first, then convert.
• Is something hiding it? Sliders, fade-in animations and scripts that reveal content all add delay after the download is done.

Once those are sorted, format really does pay off, because then the download is the slow part and a smaller file shortens it directly. For the compression side of that, our guide on how to compress images walks through quality settings, and the best image format for websites covers which format to choose page by page.

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.

Which Format Handles Wide Gamut and HDR Images?

AVIF, and it is not close. But before you go looking for it, the problem most people actually have here is the opposite one.

Start with how much colour each format can physically hold. MDN's image file type reference lists JPEG and WebP at 8 bits per channel, PNG anywhere from 1 to 16, and AVIF at 8, 10 or 12. AVIF is also the only one of the four MDN flags with explicit ICC profile support, high dynamic range and wide colour gamut. So if you are genuinely delivering an HDR photo to the web, that is the answer.

PNG is less out of the running than it used to be. The W3C PNG Third Edition adds a cICP chunk that identifies the colour space by transfer function and colour primaries, plus mDCV and cLLI chunks carrying mastering display and content light level data. It names HLG and PQ from ITU-R BT.2100 as supported HDR transfer functions. On paper PNG can now carry HDR. In practice the tooling lags the spec, so treat that as a direction of travel rather than something to ship this week.

Now the part that actually bites people, and it has nothing to do with picking a format.

Modern phones shoot in Display P3, which is wider than sRGB. The file carries a colour profile telling the browser how to read its numbers. Strip that profile out during conversion, which plenty of tools do silently, and the same numbers get interpreted as sRGB instead. The photo does not break. It just comes out looking flat, or oddly oversaturated, and nothing in the file tells you why.

Two habits fix almost all of it:

• Convert to sRGB on purpose. For ordinary web images, deliberately converting to sRGB is safer than hoping every browser handles your P3 profile the same way. Convert, do not just discard.
• Check whether your converter keeps the profile. This is the same question as the metadata section above, and the answer varies by tool rather than by format. A converter that strips EXIF often strips the colour profile with it.

The short version for most people. If your photos look duller after conversion than they did on your phone, you are not looking at a JPG versus WebP problem. You are looking at a discarded colour profile, and changing format will not fix it.

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 a separate Google study of 12,000 web PNGs found WebP lossless 42 percent smaller than PNGs made by libpng and 23 percent smaller than ones already optimised with ZopfliPNG. That gap matters: if you already run your PNGs through an optimiser, the saving is real but closer to a quarter than to a half. 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 96 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: HTTP Archive, Web Almanac 2024, Media chapter, almanac.httparchive.org, on image format shares on mobile pages (JPEG 32.4 percent, PNG 28.4, GIF 16.8, WebP 12, AVIF 1.0), two-year change since 2022, 68 percent of mobile pages with an image LCP element, and 9.5 percent of LCP images lazy-loaded. Google web.dev, Largest Contentful Paint and Optimize LCP, on the 2.5 second threshold at the 75th percentile, never lazy-loading the LCP image, and why a smaller file can shift delay rather than remove it. 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. Chromium Blink Intent to Prototype, JPEG XL decoding support (image/jxl) in Blink, posted March 2021 via the blink-dev group, on JPEG XL being royalty free, giving about 60 percent size savings against original JPEG at the same perceptual quality, and supporting HDR, animation, an alpha channel, lossless JPEG recompression and lossless and progressive modes. Chromium Blink Intent to Ship, JPEG XL decoding support (image/jxl) in Blink, posted 24 August 2026 via the blink-dev group, on the jxl-rs memory-safe pure Rust decoder, approvals from several project leads, strongly positive developer sentiment, and Cloudinary and Shopify among the parties wanting to deploy the format, with no estimated milestone listed. Mozilla dev-platform Intent to prototype, JPEG XL decoding in Rust, posted 26 January 2026, on the image.jxl.enabled preference and the explicitly exploratory framing. No browser enables JPEG XL by default outside Safari at the time of writing. Browser support figures via Can I Use, read as 96.18 percent for WebP, 94.67 percent for AVIF and 15.02 percent for JPEG XL, with JPEG XL recorded as partial support in Safari from version 17.0 and disabled by default or unsupported elsewhere. W3C, PNG Specification Third Edition, Recommendation dated 24 June 2025, section 4.9 on APNG frame-based animation, described as intended to replace simple animated images that have traditionally used GIF, and backwards compatible in that a non-animated decoder ignores the APNG chunks and displays the static image. MDN, Image file type and format guide, on APNG support from Chrome 59, Firefox 3, Safari 8 and Edge 12, and on AVIF and WebP performing better than APNG while having less broad support. Specifications and support tables change, so check the current versions before relying on a detail.