If you want one answer for a site you are building in 2026, it is WebP. It is meaningfully smaller than JPG, it handles transparency like PNG, every browser you care about has supported it for years, and practically every tool can produce it. The longer and more useful answer is that a well built site uses three or four formats, each in the place where it is genuinely strongest, and this guide tells you which to reach for.
The candidates and what each is actually good at
JPG
Still the most universally understood image format on earth. Lossy, no transparency, no animation. Its compression is tuned for photographs, and at quality 80 or above it looks fine. In 2026 its main job is to be the safety net: the file you serve when something exotic goes wrong, and the format every upload form, email client and print service accepts without argument.
PNG
Lossless, supports full alpha transparency, and it does not blur fine detail. That makes it excellent for screenshots with small text, UI mockups, diagrams with hard edges, and any master file you intend to edit again later. Its weakness is photographs, where a PNG can easily be five to ten times the size of an equivalent JPG for no visible benefit.
WebP
Google’s format, and the pragmatic winner. It has both a lossy mode (better than JPG at the same visual quality) and a lossless mode (usually smaller than PNG), plus alpha transparency and animation. As a rule of thumb, expect a lossy WebP to land roughly 25 to 35 percent below a JPG of comparable quality, though the exact saving depends heavily on the image.
AVIF
Based on the AV1 video codec. It generally compresses better than WebP, especially at low bitrates and on images with gradients or flat colour areas, and it handles wide colour gamut and HDR properly. The trade-off is encode time and ecosystem maturity, covered below.
SVG
Not a pixel format at all. SVG describes shapes with maths, so it is perfectly sharp at any size and any pixel density, and a clean icon is often only a few hundred bytes. Use it for logos, icons, charts, diagrams and simple illustrations. Never use it for photographs.
GIF
Obsolete for anything except nostalgia. It is capped at 256 colours, has only on or off transparency, and its animation compression is terrible. A short muted MP4 or WebM video is normally a fraction of the size of the equivalent GIF, and animated WebP is a good middle ground when you need something that behaves like an image.
Why WebP is the safe default
Three things make WebP the right starting point rather than a compromise.
Support is not a question any more. Chrome, Firefox and Edge have handled WebP for the better part of a decade, and Safari added it in version 14 back in September 2020. Any browser still in meaningful use in 2026 opens WebP without help.
One format covers both jobs. Photographs go through lossy WebP, and graphics, screenshots and logos with transparency go through lossless WebP. You no longer need to decide between the JPG pipeline and the PNG pipeline, which removes a whole class of mistakes from a content workflow where non-technical people upload images.
Tooling is everywhere. Every static site generator, CMS, CDN and image library speaks WebP. If you are converting by hand, JPG to WebP and PNG to WebP run the encode in your own browser using the Canvas API and the browser’s built-in WebP encoder, so the images never leave your machine. That matters more than it sounds when you are handling client work or unreleased product screenshots.
If you want a deeper side-by-side, we compared the three workhorse formats in WebP vs PNG vs JPG.
Where AVIF wins, and what it costs
AVIF is the better compressor. On photographic content it often reaches the same perceived quality as WebP at a noticeably smaller size, and it degrades more gracefully when you push the quality down hard. It also avoids the blotchy banding that WebP can show on skies and soft gradients.
The costs are real though:
- Encoding is slow. Producing a good AVIF can take several times longer than a WebP. On a build server that is an annoyance; in a browser tab or an interactive upload flow it is a genuine user experience problem.
- Tooling coverage is uneven. Browser support is broad now, but CMS plugins, older CDN image pipelines, design handoff tools and some CI images still lag. You may find that your host resizes and converts to WebP automatically but not to AVIF.
- Small images do not benefit much. AVIF carries more container overhead, so for a 40x40 avatar or a tiny icon it can end up larger than WebP. Test rather than assume.
The sensible posture in 2026: serve AVIF where your pipeline can generate it reliably, always with a WebP fallback, and do not rebuild your whole stack for it. And a word on JPEG XL, since people ask: it is technically impressive, but browser support has been inconsistent enough that it is not something to build a production site around today.
A decision table by image type
| Image type | First choice | Fallback | Why |
|---|---|---|---|
| Hero photograph | AVIF | WebP, then JPG | Biggest file on the page, so the best compressor pays off most |
| In-content photos | WebP | JPG | Simple pipeline, excellent size, universal support |
| Product shot with transparency | WebP (lossy + alpha) | PNG | WebP keeps alpha at a fraction of PNG’s size |
| Logo, icon, UI glyph | SVG | WebP | Sharp at any density, tiny, styleable with CSS |
| Chart or diagram | SVG | PNG (lossless) | Text and lines stay crisp when zoomed |
| Screenshot with small text | PNG or lossless WebP | PNG | Lossy compression smears type at small sizes |
| Animation | MP4 or WebM video | Animated WebP | Video codecs crush GIF on size and quality |
| Email or upload attachment | JPG | none | Maximum compatibility outside the browser |
| Print or archival master | PNG or TIFF | none | Lossless, no generation loss when re-edited |
Note that Tinyvert produces still images only. For animation, export a video from your editor rather than looking for an image converter.
Serving modern formats with the picture element
The browser picks the first source whose type it understands, and downloads exactly one file. Nothing is wasted.
<picture>
<source srcset="/img/hero.avif" type="image/avif">
<source srcset="/img/hero.webp" type="image/webp">
<img src="/img/hero.jpg"
alt="Team reviewing a dashboard on a laptop"
width="1200" height="675"
fetchpriority="high" decoding="async">
</picture>
Three details people get wrong. Order matters, because the browser takes the first match and does not compare sizes, so put your smallest format first. The img tag is required, since it carries the alt text and is what the browser actually renders. And always set width and height, even when CSS resizes the image, because those attributes let the browser reserve the right space and avoid a layout shift.
Size the image before you compress it
The single biggest win available to most sites is not the format at all. It is that a 4000 pixel wide camera file is being served into a 600 pixel wide column. Compression settings argue over kilobytes; correct sizing saves megabytes.
Export at the largest size the image is actually displayed at, then roughly double it for high density screens, and stop there. For images whose display size changes with the viewport, hand the browser a set of options:
<img src="/img/card-800.webp"
srcset="/img/card-400.webp 400w,
/img/card-800.webp 800w,
/img/card-1600.webp 1600w"
sizes="(max-width: 700px) 100vw, 350px"
width="800" height="450"
alt="Packaging design samples"
loading="lazy" decoding="async">
The sizes attribute is the part that gets skipped, and it is the part that does the work. It tells the browser how wide the image will be before layout has happened, so it can choose the right file. Get it wrong and a phone happily downloads the 1600 pixel version.
For one-off work, the image resizer will scale to an exact width or height in the browser, and the image compressor will squeeze what is left. Our guide on compressing images without losing quality goes into how far you can push the quality slider before anyone notices.
Lazy loading, fetchpriority and Core Web Vitals
Images are usually the reason Largest Contentful Paint is slow, because the largest element on a typical page is a picture. LCP is considered good at 2.5 seconds or less, and it is measured from when navigation starts, so every kilobyte in front of the hero image counts against you.
A few rules that reliably help:
- Do not lazy load your hero.
loading="lazy"on an above-the-fold image delays the exact request you most want early. Lazy load everything below the fold, and nothing above it. - Mark the LCP image as high priority.
fetchpriority="high"raises the image’s priority so the browser requests it earlier than it otherwise would, ahead of the page’s other images. Support is wide, and browsers that ignore it are no worse off than before. - Always reserve space. Missing dimensions cause Cumulative Layout Shift as images pop in and push text around.
- Watch background images. A CSS
background-imageis discovered late, after the stylesheet parses. If your hero is a background, it starts downloading later than a realimgtag would.
Format choice feeds directly into this. Cutting a 900 KB hero JPG to a 300 KB WebP can move LCP by a noticeable amount on a mid-range phone over mobile data, which is where most of your traffic lives.
A workflow for converting an existing library
If you have an existing site with a pile of JPGs and PNGs, work in this order.
- Find the worst offenders first. Run a page through your browser’s network panel, sort by size, and deal with the top ten images. A small number of files almost always accounts for most of the weight.
- Resize before converting. Check the rendered display width in devtools, then export at that width times two. Do this first, because every later step operates on fewer pixels.
- Convert to WebP. Photographs go lossy at around 80. Screenshots and flat graphics go lossless. Use JPG to WebP and PNG to WebP for small batches.
- Replace logos and icons with SVG. Ask your designer for the vector files. This is often the easiest permanent win on the whole site.
- Keep a fallback path. Either keep the original JPG next to the WebP and use a
pictureelement, or confirm your CDN can negotiate formats by content type. - Automate what remains. Once the manual pass proves the savings, move the conversion into your build step or your image CDN so new uploads are handled without anyone remembering to do it.
Tinyvert is built for steps 2 and 3: quick, private, one-off conversions where everything runs in your browser tab and nothing gets uploaded. The free tier handles 5 files per batch, which suits most manual cleanups. If you need a browser-based converter in the other direction, for example to hand a WebP to a client whose software cannot open it, WebP to JPG and WebP to PNG do that too.
For a site of any real size though, be honest with yourself: a build-time image pipeline or a CDN that converts on the fly will beat any manual process, because it keeps working after you stop paying attention.