The practical answer
Image compression is not a contest where one format wins every time. It is a set of tradeoffs: what detail you can discard, what detail must stay exact, how much CPU time you can spend, and where the file has to work after export.
Use this as the practical starting point:
- Use JPEG for photos that need maximum compatibility, especially email, downloads, older apps, print portals, and strict upload forms.
- Use PNG for screenshots, UI captures, diagrams, logos, and transparent graphics when pixels must stay exact.
- Use WebP as the everyday modern web format when you want smaller files than JPEG or PNG with broad browser support.
- Use AVIF for large, high-traffic photographic images when your site can serve WebP or JPEG fallbacks and can tolerate slower encoding.
That sounds simple, but the details matter. A product photo, a passport photo, a software screenshot, and a transparent watermark are all "images." They do not compress the same way.
Choose by the job, not by the file extension
Before getting into codecs, decide what the image is supposed to do:
| Image job | Better first choice | Why |
|---|---|---|
| Camera photo for a blog post | WebP, with JPEG fallback when needed | Smaller than JPEG in many web workflows, still easy to automate |
| Photo for an upload form | JPEG | The receiving system is more important than theoretical compression |
| Large homepage hero | AVIF first, WebP second, JPEG fallback | The file is big enough that extra compression can matter |
| Product photo with labels or texture | WebP, then test AVIF | Small artifacts around labels, fabric, and edges can affect trust |
| UI screenshot or software tutorial | PNG or lossless WebP | Text and hard edges should stay crisp |
| Transparent logo or watermark | PNG, WebP, or AVIF depending on target support | JPEG cannot keep transparency |
| Editable master file | PNG, TIFF, PSD, or original camera format | Do not store your only master as a repeatedly edited JPEG |
| Email newsletter image | JPEG or PNG | Email client support is less predictable than browser support |
| Archive copy | Original plus a lossless export if needed | Compression should not destroy future editing options |
This is also why format advice can feel contradictory. "Use AVIF because it is smaller" can be good advice for a hero image in a static-site build. The same advice can be bad for a customer-uploaded image that must be accepted by a government form, email client, or older CMS.
The two compression families
Every image format in this guide uses either lossless compression, lossy compression, or both.
Lossless compression removes mathematical redundancy and reconstructs the same pixels on decode. If a screenshot has a white background, repeated interface colors, and repeated straight edges, a lossless format can describe those patterns compactly. PNG is the classic lossless web format. WebP also has a lossless mode.
Lossy compression permanently discards image information to make the file smaller. The trick is to discard the information people are less likely to notice at the final viewing size. JPEG is lossy. WebP and AVIF can be lossy or lossless, though most website delivery uses their lossy modes for photos.
The mistake to avoid is treating "lossy" as automatically bad and "lossless" as automatically professional. For a 1600 px blog photo, a carefully compressed lossy WebP can look unchanged in the page and save a lot of bandwidth. For a software screenshot with small menu text, a lossy export can look fuzzy even if the file size looks great.
The four formats at a glance
| Format | Main compression idea | Lossy or lossless | Best-fit jobs | Watch out for |
|---|---|---|---|---|
| JPEG | 8x8 DCT blocks, quantization, often chroma subsampling | Lossy | Photos, compatibility, upload forms | No transparency, generation loss, artifacts around text |
| PNG | Per-line filtering plus DEFLATE compression | Lossless | Screenshots, diagrams, logos, transparent graphics | Very large camera photos |
| WebP | VP8-style predictive coding for lossy, separate lossless coding | Both | Modern web photos, thumbnails, mixed image libraries | Some email, app, CMS, and print workflows still reject it |
| AVIF | AV1 image coding stored in an HEIF-based container | Both | Large photos, high-traffic pages, HDR or wide-gamut workflows | Slower encoding and more need for fallbacks |
The pattern is not "newer always wins." Newer formats can do more analysis and pack data more efficiently, but that can cost encoding time, QA time, and fallback complexity.
Why the same quality number is not the same quality
A JPEG saved at quality 80 and a WebP saved at quality 80 are not using the same scale. The number is passed into each encoder's own model. It affects different internal decisions and it may be mapped differently by different tools.
That is why practical image compression needs two checks:
- Look at the image at the size where it will appear. A product-card thumbnail should be judged as a product-card thumbnail, not at 400 percent zoom.
- Compare bytes after the image has the right dimensions. Resizing a 5000 px camera original to a 1600 px web image usually saves more than pushing a quality slider too low.
If you are batch-converting a folder, test a few hard cases before exporting everything: a face, a sky, a dark shadow, a text-heavy screenshot, a transparent edge, and a noisy indoor photo.
JPEG: why photos get small, and why text gets ugly
JPEG is the old workhorse for photographic images because it is built around how photos behave. The Library of Congress notes that the JPEG family is commonly used for continuous-tone full-color and grayscale images, and the classic process uses an 8x8 block transform. In plain English: JPEG chops the image into small blocks, turns each block into frequency information, then quantizes details the viewer is less likely to notice.
That works well for:
- faces, clothing, buildings, landscapes, and food photos;
- natural gradients such as sky, shadows, and skin tones;
- images that do not need transparent pixels;
- files that must open almost anywhere.
It works poorly for:
- small text in screenshots;
- icons and logos with hard edges;
- flat-color diagrams;
- files that will be repeatedly edited and re-exported;
- transparent images, because JPEG has no alpha channel.
The most recognizable JPEG artifacts are block edges, ringing around text, mosquito noise around high-contrast details, and banding in smooth gradients. These are not random. They are the visible side effects of block-based lossy compression.
Strengths
- Very broad support across browsers, operating systems, apps, email clients, forms, and vendors
- Efficient for camera photos and other continuous-tone images
- Fast to encode and decode in common workflows
- Easy to preview, attach, upload, and share
Weaknesses
- No transparency support
- Artifacts around text, edges, and flat-color graphics
- Repeated lossy exports can compound damage
- Often larger than WebP or AVIF at similar visible quality for web photos
When to use JPEG
Use JPEG when compatibility matters more than the last few kilobytes: passport-photo uploads, document portals, email attachments, vendor portals, print shops, older CMS systems, and fallback <img> sources. Also use it when the file is mainly a photo and transparency is not needed.
PNG: why screenshots stay sharp, and why photos get huge
PNG was designed for portable, lossless raster images. The W3C PNG specification covers static PNG and animated PNG, and the format supports indexed color, grayscale, truecolor, and optional alpha transparency.
For everyday website work, the key point is simple: PNG keeps the pixels. It can filter image rows to make them more predictable, then compress the result with DEFLATE. If the image has repeated colors and sharp boundaries, that works beautifully.
Good PNG candidates:
- software screenshots with small text;
- UI diagrams and comparison tables exported as images;
- logos when SVG is not available;
- transparent overlays, stamps, and watermarks;
- graphics that may be edited again.
Bad PNG candidates:
- camera photos;
- large website hero images;
- product photos with natural texture;
- gallery images where file size matters more than exact pixels.
A PNG photo is often huge because PNG is doing its job. It is preserving noise, fine texture, tiny sensor variations, and every subtle color change that a lossy photo codec would simplify.
Strengths
- Lossless pixel reproduction
- Alpha channel transparency
- Crisp text and hard edges
- Strong compression for flat-color and repetitive graphics
- Reliable format for editing masters and transparency workflows
Weaknesses
- Large files for photographs
- No lossy mode in normal PNG workflows
- Can be heavier than WebP for transparent web graphics when WebP is accepted
When to use PNG
Use PNG when exact pixels matter: screenshots, UI documentation, diagrams, simple graphics, and transparent assets that need predictable support. Do not use PNG as the default for camera photos unless you intentionally need a lossless working copy.
WebP: the practical modern web default
WebP is useful because it covers several jobs in one format. Google's documentation describes WebP as supporting lossy compression, lossless compression, transparency, animation, metadata, and color profiles. That makes it more flexible than JPEG and often smaller than PNG for web delivery.
Lossy WebP is based on VP8-style predictive coding rather than JPEG's older DCT-only workflow. Lossless WebP uses a different set of transforms and entropy coding. The important practical result is that WebP is often a good default for website image libraries: blog photos, product grids, thumbnails, lightweight illustrations, and many transparent assets.
But WebP is not magic, and it is not the best file to send everywhere. A browser can support WebP while an email client, upload form, older design app, social platform, or print workflow rejects it. That is why JPEG and PNG still matter as delivery or compatibility formats.
Strengths
- Often smaller than JPEG for photos at similar visible quality
- Supports alpha transparency
- Supports lossy and lossless modes
- Broad modern browser support
- Fast encoding compared to AVIF
Weaknesses
- Still rejected by some email clients, forms, older apps, CMS plugins, and print workflows
- Not a true replacement for SVG logos or editable design source files
- May be larger than AVIF for some large photographic images
When to use WebP
Use WebP for most modern website image delivery when you control the page. It is a strong default for blog images, product-card photos, thumbnails, and many transparent web assets. Keep JPEG or PNG available when the image leaves your website and enters someone else's system.
AVIF: the high-compression option that needs a pipeline
AVIF stores AV1-coded image data in an HEIF-based image format. The AVIF specification includes support for SDR and HDR images, wide color gamut use cases, auxiliary images such as alpha, and more advanced image coding features. web.dev also notes that AVIF's compression gains depend on image content, encoder settings, and the quality target.
For normal website teams, the practical story is this: AVIF can be excellent for large photos, but it is more of a pipeline format than a casual sharing format. It can take longer to encode, preview support can lag in older tools, and fallback handling matters more.
Good AVIF candidates:
- large hero photos;
- photo-heavy landing pages;
- editorial galleries;
- high-traffic images served many times after one encode;
- images where HDR, high bit depth, or wide color gamut are part of the workflow.
Weak AVIF candidates:
- strict upload forms;
- email attachments;
- images that teammates need to open in older tools;
- tiny thumbnails where the savings may not justify pipeline complexity;
- screenshots with small text unless you test carefully.
Strengths
- Often excellent compression for photographs and complex imagery
- Alpha transparency, HDR, and wide color gamut
- Useful as the first source in a modern
<picture>stack - Strong fit for build-time or CDN image generation
Weaknesses
- Encoding can be slow, especially for large batches
- Tool support is less predictable than JPEG, PNG, or WebP
- Needs WebP, JPEG, or PNG fallback for safer production delivery
When to use AVIF
Use AVIF when the image is big enough and repeated enough that smaller bytes justify the extra pipeline work. A hero image on a high-traffic homepage is a good candidate. A 90 px icon, a one-off email attachment, or a government upload form usually is not.
Why PNG can beat JPEG on screenshots
A common surprise: a PNG screenshot can be smaller and cleaner than a JPEG screenshot.
That happens because screenshots are often full of repeated structure. A white document background, a gray toolbar, straight black text, a few icon colors, and repeated UI spacing are easy for lossless compression to describe. JPEG does not know that the text should stay exact. It tries to simplify the image like a photo, and the result can be a file that is not much smaller but looks worse around letters and edges.
If the screenshot is mostly a photo, WebP or JPEG may win. If it is mostly interface, text, and flat color, start with PNG or lossless WebP.
Why photos need lossy compression
Camera photos are different. They contain sensor noise, fine texture, soft shadows, irregular gradients, and millions of tiny changes from pixel to pixel. Lossless compression has less repetition to exploit, so it often cannot reduce the file enough for web delivery.
Lossy photo formats work because a viewer usually cares about the subject, composition, color, and perceived sharpness, not every original pixel. A carefully compressed JPEG, WebP, or AVIF can remove information that is difficult to see at the final display size.
The danger is pushing too far. Low quality settings can flatten skin, smear fabric, destroy leaf detail, add block edges, or create banding in sky and shadows. If those areas matter to the image, use a higher quality setting or a larger display file.
Use fallbacks for modern web delivery
When you control a website, you do not have to choose only one format. The common production pattern is to serve the smallest modern format first and keep safer fallbacks behind it.
<picture>
<source srcset="/images/hero.avif" type="image/avif">
<source srcset="/images/hero.webp" type="image/webp">
<img
src="/images/hero.jpg"
alt="Close-up product photo in natural light"
width="1200"
height="800"
>
</picture>
The browser uses the first source it supports. AVIF-capable browsers can get the AVIF file. Browsers that do not use AVIF can try WebP. Older or stricter clients still have the JPEG fallback.
Use PNG instead of JPEG as the fallback when the image needs transparency or exact text.
A practical compression workflow
For one image:
- Start from the highest-quality source you have.
- Resize to the largest real display size first.
- Choose the format based on the image job.
- Export one or two quality settings.
- Compare the result in the actual page or upload destination.
- Keep the master file so you do not need to recompress the published copy.
For a website folder:
- Pick a representative set before converting the full batch.
- Include photos, screenshots, transparent graphics, thumbnails, and one difficult dark image.
- Test WebP as the baseline modern format.
- Test AVIF only where byte savings would matter.
- Keep JPEG or PNG fallbacks for places that need them.
- Check file size after resizing, not before.
PhotoTools can help with the middle steps. Use Resize when the source is too large for the page, Compress to adjust file size and quality, and the format converters when a destination needs a specific file type. The conversion and compression happen in your browser, so the image is not uploaded to a server during the tool workflow.
How to convert between formats
PhotoTools converts between JPG, PNG, WebP, AVIF, and HEIC directly in your browser. Drop in your images, choose the target format, preview the result, and download the new file.
Use the converter based on the destination:
- Need a file that works in almost any form or app? Convert to JPEG.
- Need transparency or exact screenshot pixels? Convert to PNG or lossless WebP.
- Need a smaller web image and the site accepts it? Convert to WebP.
- Need maximum compression for a controlled website pipeline? Test AVIF with a fallback.
One last rule saves a lot of image quality: do not bounce between lossy formats repeatedly. If a photo started as a high-quality JPEG, converting JPEG to WebP can be fine for delivery. Converting that WebP back to JPEG, editing it, and converting it again is where artifacts pile up. Go back to the original whenever possible.