You have an image. You are about to save it as something. The default that pops up in your tool is whatever the tool's developer happened to ship with — Photoshop offers JPG, Figma offers PNG, browser screenshots end up as PNG, an iPhone gives you HEIC and then someone tells you to "convert to JPG for compatibility." None of these defaults are wrong, but they are also rarely right.
Three formats cover roughly 95% of all web and casual image use: WebP, JPG, and PNG. Each one was designed for a specific job, and the picking rule is short enough to memorise. The short version: default to WebP for the web, ship JPG when you need universal compatibility, reach for PNG only when you need transparency or a pixel-perfect screenshot. The longer version — with the file-size numbers that make the case — is below.
Convert an image to WebPThe 10-second decision tree
If you don't read the rest of this, this is the summary:
- Photo on the open web (blog post, marketing page, product gallery, social preview) → WebP. Smaller, same quality, supported everywhere that matters.
- Photo being emailed, attached, or sent to a non-web destination (Word doc, print shop, photo lab, family member's iPhone) → JPG. Maximum compatibility, no questions.
- UI screenshot, diagram, logo, illustration, anything with text or hard edges → PNG. Lossless, transparency, no JPG ringing artifacts around the type.
- Logo or icon that needs to scale → not any of these — SVG. Pixel formats blur when you scale up; vectors don't.
That's the rule. The rest of this post is the why, with real numbers so you trust it on the next ambiguous case.
What the three formats actually do differently
Each format trades a different thing for size.
| Format | Compression | Transparency | Best for | Weak at |
|---|---|---|---|---|
| WebP | Lossy or lossless (you pick) | Yes (in lossless mode and lossy alpha) | Web photos, hero images, social previews | Print labs, old desktop apps, some email clients |
| JPG | Lossy only | No | Universal compatibility, email, print | Text, line art, transparency, anything re-saved repeatedly |
| PNG | Lossless | Yes | UI screenshots, logos, diagrams, transparency | Photos — PNG of a photo is typically 3–6× bigger than JPG of the same photo, for no visible benefit |
WebP is the newest of the three (Google released it in 2010 and it took a decade to land in Safari, which is why some people still treat it as bleeding-edge — it isn't, it's been universally supported since iOS 14 in 2020). PNG is from 1996. JPG is from 1992. The web has had over thirty years to settle into roles for these, and the roles are stable.
Real numbers: the same photo, three formats
This is the part that makes the case better than any abstract argument. A 4032×3024 iPhone photo of a coffee cup, exported at default quality through this site's converters:
- JPG (quality 85): 1.42 MB
- WebP (quality 85, lossy): 0.71 MB — 50% smaller, visually indistinguishable
- PNG (lossless): 7.34 MB — 5× larger than JPG, for zero visible benefit on a photo
Now a 1920×1080 screenshot of a settings panel — flat backgrounds, text, a few buttons:
- PNG (lossless): 0.18 MB — sharp text, pixel-perfect
- WebP (lossless): 0.14 MB — same quality, ~20% smaller, but PNG is more portable for "drop into a Slack thread" use
- JPG (quality 85): 0.21 MB — larger than PNG for this content type, and the text edges develop the classic JPG colour halos. Wrong tool.
That second example is the one people get wrong most often. They reach for JPG out of habit on a screenshot, end up with a larger file and blurry text. JPG was designed for photographs — smooth tonal gradients — and it actively hurts the file when the source is mostly flat fields of one colour with hard edges between them.
Why WebP isn't the default everywhere yet
Two reasons, neither technical.
One: legacy software. Photoshop didn't support WebP natively until 2022. macOS Preview didn't export WebP until Ventura. Email clients still vary — Outlook 2016 won't preview a WebP attachment, though it will save it. Print kiosks at Walgreens and FedEx accept JPG and PNG only. If the destination is any of those, ship JPG and stop fighting it.
Two: muscle memory. Every "Save As" dialog you've used for twenty years offered JPG and PNG. WebP got added later, often hidden under "Other formats" or "Show all." The format choice didn't change; the dialog did. People keep picking JPG because that's where their cursor lands.
On the open web — a blog post you control, a product page you ship to a CDN, a Twitter/X image preview — none of that applies. Every modern browser has supported WebP for years. Convert the photo to WebP and ship a page that's half the weight.
The cases where each format wins
WebP wins when you control the destination
Your own website. Your own marketing pages. Hero images, product photography, blog illustrations, OG share images. Anything that's going to be served through HTTPS to a browser. WebP saves roughly half the bandwidth compared to the same JPG and is visually identical. On mobile users on a slow connection, that is the difference between a page loading in 1.4s and 2.7s. Google's Core Web Vitals counts the second one against you.
To convert a folder of photos to WebP for a site rebuild, the workflow on this site is: open /image-to-webp, drop in the whole folder, leave the quality slider at 85 (the default sweet spot), hit "Download all (ZIP)." The offline-pill at the bottom of the page stays lit the whole time because nothing leaves the device — the conversion runs in WebAssembly inside the page. For an already-optimised JPG that's still too big, route through /compress-webp or compare against /compress-jpg with the strip-metadata toggle on.
JPG wins when you don't control the destination
Email attachments. A photo printer at a drug store. A document going into Word, PowerPoint, or Pages and then to a colleague who'll open it on an old machine. An iPhone screenshot you're texting to your parents. A file you're posting to an old forum or a Craigslist listing. Anything where you cannot guarantee what's going to open it.
JPG is the format that always works. It's been universal for so long that there is essentially no software on Earth that doesn't render it. For the "send a photo" case, compress JPG for email covers the workflow. For HEIC-vs-JPG specifically — the iPhone-photo-going-anywhere case — iPhone HEIC vs JPG is the deep dive.
PNG wins on screenshots, UI, and transparency
If the image has flat colour areas, text, or hard edges — basically anything that didn't come out of a camera — PNG. The lossless compression is genuinely smaller than JPG on this kind of content, the text stays sharp, and you get transparency for free.
Common cases: a screenshot of a Stripe dashboard for a bug report. A logo on a transparent background going into a slide deck. A diagram in a design doc. A favicon. App icons before they get downsized. UI mocks in a Figma export. For the photography case where PNG seems like the safe choice "because it's lossless" — resist; compress PNG without losing quality walks through why PNG of a photo is the wrong tool, and what to do about a 7MB PNG that should have been a 1MB JPG.
The format you don't want: any of these, if the image needs to scale
WebP, JPG, and PNG are all raster formats — grids of pixels. They look fine at their native size, and they fall apart when you blow them up beyond it. A 200×200 logo blown up to 1600×1600 will be visibly jagged or blurry no matter which of the three you picked.
Logos, icons, and illustrations meant to scale should be SVG — a vector format that re-renders cleanly at any size. Convert image to SVG vector covers when an auto-trace is good enough and when you actually need an illustrator to redraw the asset.
A workflow that scales: convert once, ship in two formats
For sites that want to be honest about old browsers and old email clients, the standard pattern is to ship both formats and let the browser pick:
<picture>
<source srcset="/hero.webp" type="image/webp">
<img src="/hero.jpg" alt="..." width="1280" height="720">
</picture>
Modern browsers grab the WebP. The four people still on something that doesn't speak WebP fall through to the JPG. The HTML is two lines longer; the page is half the weight for everyone who matters. To generate the pair, drop the source into /image-to-webp for the WebP, then /image-to-jpg for the JPG fallback — both runs are local, both run on the same source image, and the quality slider lets you match the visual targets manually if you care.
Open the image converterEdge cases worth knowing
- Animated GIFs. Animated WebP exists and is smaller, but GIF still has wider support in chat apps and old email. For new pages, prefer MP4 or animated WebP; for "drop it in Slack," GIF still works fine.
- HEIC. Apple's iPhone format. Half the size of JPG but supported almost nowhere outside the Apple ecosystem. Treat HEIC as a storage format on the phone and convert to JPG or WebP before it leaves the device. See why HEIC won't open on Windows.
- AVIF. The next-next-generation format after WebP — smaller again, also lossless or lossy. Support is broad but not yet universal. For 2026, WebP is the safe bet; AVIF is the bleeding-edge optimisation if you're already shipping WebP and want another 20% off the bytes.
- RAW. Camera RAW formats (.NEF, .CR2, .ARW, .DNG) are not destinations — they're the negative. Convert RAW to one of these formats before publishing, never the other way.