pythonware.com

Home / Image tools / compress to 200 KB

Byte budget · 200 KB ceiling

Compress an image to 200 KB

Two hundred kilobytes is about the largest single image a page can afford before it starts hurting load time on a mobile connection. This page compresses to that budget twice, once as JPEG and once as WebP, and shows you both so the choice is informed rather than assumed.

Drop a file here or click to browse — JPG, PNG or WebP

Two results

Compressed result

Why compress to a budget rather than a quality setting

Most image tools ask you to pick a quality percentage and then tell you what size you got. That is backwards for web work. A page has a performance budget measured in bytes, not in quality percentages, and the same quality setting produces wildly different file sizes depending on the picture. Starting from the byte budget and letting the encoder find the quality that fits keeps the page predictable.

The comparison matters because WebP is not uniformly better. On photographs it usually wins by 20–30% at matched visual quality. On images with large flat areas and hard edges it can win by far more. Occasionally, on small or already heavily compressed sources, it wins by nothing at all. Rather than repeat the general claim, this tool measures it on your actual file.

What to do with the result

  • If WebP is meaningfully smaller, serve it and keep the JPEG as a fallback. Every browser released in the last six years supports WebP, but a fallback costs you nothing.
  • Add width and height attributes to the tag. It stops the page shifting as images load, which is the layout stability half of Core Web Vitals.
  • Only the image at the top of the page needs to load eagerly. Everything below the fold should carry loading="lazy".

Common questions

Should I use WebP or AVIF?

AVIF compresses better again, often another 20% below WebP, but it is slow to encode and no browser can create it from a canvas, so it cannot be produced by a tool like this one. If you have a build pipeline, AVIF with a WebP fallback is the strongest option. If you are working by hand, WebP is the pragmatic choice.

Does compressing images actually improve my Core Web Vitals?

It improves Largest Contentful Paint, which is usually the metric a heavy hero image is damaging. It does nothing for Interaction to Next Paint, which is a JavaScript problem, and it only helps Cumulative Layout Shift if you also declare the dimensions in the markup. Image weight is one lever of three.

My PNG logo came out looking rough.

Logos and line art should not go through a lossy encoder at all. Keep them as PNG or, better, as SVG. This page is built for photographs.

Why is the WebP file sometimes bigger than the JPEG?

Because the search stops at the highest quality that fits your budget, and if both formats reach the ceiling comfortably they both stop near the top of their range, where WebP's advantage is smallest. It also happens with very small images, where WebP's container overhead is a larger share of the total.

Other image tools