Choose the format for the job
| Format | A useful starting point | Watch for |
|---|---|---|
| AVIF | Photos and detailed web imagery when you want a small delivery file. | Encoding can be slow. Confirm that the target app, platform or workflow accepts AVIF. |
| WebP | Web photos, product images and assets that need transparency. | Fine text and sharp edges may need a higher quality setting or a lossless version. |
| PNG | Screenshots, diagrams, logos, pixel art and transparent graphics. | Large photographs can remain very large. Palette reduction can change colors. |
| JPEG | Photographs for workflows that expect a familiar, broadly supported format. | No transparency. Repeated lossy encoding can accumulate visible damage. |
These are starting points, not a ranking. A transparent icon and a full-screen photo can favor different formats even when they appear on the same page. If the destination has its own upload requirements, follow those first.
First, use the dimensions you need
Pixel count has a large effect on file size. A 6000-pixel-wide photograph is usually unnecessary for a small card on a website. Resize to the intended display size, allowing for the pixel density you plan to support.
For example, an image displayed at 800 CSS pixels wide might use a 1600-pixel-wide source for a 2× display. This is a planning example, not a universal requirement: responsive layouts, cropping and delivery bandwidth affect the right choice.
Then adjust quality
For lossy formats, a quality control changes how much information the encoder can discard. Quality values are codec-specific: “80” in JPEG is not the same visual promise as “80” in WebP or AVIF.
- Start with a balanced setting and inspect the result at its intended display size.
- Zoom to 100% and compare important areas: faces, gradients, text, small textures and edges.
- Lower quality in small steps until you see a change that matters, then move back up.
- Keep the version that meets your quality needs with the smallest useful file.
Look at the result, not just the percentage
A large reduction is easy when the source is oversized or inefficiently encoded. It does not, by itself, prove that an encoder is better. Compare the same dimensions, transparency and visible quality.
Understand PNG: lossless and palette reduction
PNG's compression of its encoded pixel data is lossless. But a tool can alter that data before it is encoded. Reducing an image to a smaller palette merges similar colors, which can reduce file size and also introduce a visual change.
A strict lossless workflow preserves decoded pixels while changing the way they are stored. A palette workflow can be useful for simple artwork, but smooth gradients, soft shadows and semi-transparent edges need closer inspection. Dithering can hide color steps by introducing a fine pattern; it can also make flat areas noisier.
If exact pixel values are a requirement, select a lossless workflow and compare the result accordingly. A format name alone does not guarantee that the entire conversion was lossless.
Handle transparency deliberately
PNG, WebP and AVIF can store an alpha channel. JPEG cannot. When converting a transparent image to JPEG, choose a background color that matches where the image will be used. Otherwise a cutout, logo or shadow can gain an unwanted background or edge.
Inspect transparent edges against both a light and a dark background. A result that looks clean on white may show a halo on a dark page.
AVIF: small files can take more work
AVIF offers useful compression options, but encoding effort can be substantial. Higher encoder effort is a different control from visual quality: it lets the encoder spend more time looking for an efficient representation.
Try AVIF for a photo that will be reused many times. For a quick batch on a phone, WebP or JPEG may be a more comfortable starting point. There is no fixed time promise because image size, content, settings and device performance all matter.
Keep originals, metadata and color in mind
Re-encoding can remove EXIF, location and other metadata. Keep the original when those details matter. Browser decoding and encoding can also affect color profiles, high dynamic range data or orientation metadata; check color-critical work in its final destination.
Repeatedly editing a previously compressed lossy file can reduce quality. When possible, generate each delivery version from the original.
When a batch is slow or fails
A decoded image takes more memory than its compressed file. A 6000 × 4000 image needs roughly 96 MB for one 8-bit RGBA pixel buffer; decoding, resizing and encoding can require several buffers at once.
If a tab becomes slow, try fewer files at a time, smaller dimensions or a faster output format. A corrupt file, an unsupported image variant or limited device memory can also prevent processing. Save useful results before closing or refreshing the page.
Ready to make it smaller?
Choose your images and prepare a lighter version, right in your browser.

