Tool · free & in your browser
How much lighter could your image be?
Drop an image in, read the result: the calculator shows how much smaller your image would be as a scaled WebP – computed on your device, no upload.
Image diet calculator
Your image on a diet
Drag an image into the box – the calculator scales it to the 1,600 px target width and encodes it as WebP to compare file sizes. Both happen locally in your browser.
Your image stays on your device – the maths happens right in your browser. We transfer and store nothing.
An estimate for exactly this target width and quality level, not a finished optimisation: the best value depends on subject, placement and quality requirements.
One limit is in the method itself: the encoding is done by your browser's WebP encoder, and different encoders arrive at different file sizes at the same quality setting. Your CMS will rarely produce exactly the same figure. The order of magnitude holds, the last digit does not. For deciding whether an image is worth working on, that is enough. How WebP and AVIF compress is set out in the glossary entry on image compression.
How professionals optimise images
Four steps, in this order – the slider above replaces none of them, but it shows the potential.
-
Step 1
Scale properly
Never serve an image wider than needed: content images rarely need more than 1,600 px, full-width visuals 2,400 px. Scaling often saves more than any compression.
-
Step 2
Modern format
WebP as the default for photos, AVIF where your stack supports it. PNG only for graphics with hard edges, SVG for logos and icons.
-
Step 3
Compression per subject
Quality 75–85 % suits most photos. Gradients and skies need more, detailed subjects tolerate less – try it with the slider above.
-
Step 4
Automate it
Size variants, format selection and lazy loading belong in the CMS, not in manual work. Set up once, every future image is right automatically.
Small files alone do not solve the problem, because not every image matters equally. What counts for perceived load time is above all the largest image in the first screenful. Lazy loading on that one image makes the page slower, not faster. It is then only requested once the browser has loaded everything else. Which measurement captures this is explained in the glossary entry on Largest Contentful Paint. For every image further down the page, lazy loading is exactly right.
Images are usually the biggest loading-time lever
On typical business websites, images are usually the largest share of transferred data – properly scaled and served as WebP, the transferred volume drops considerably and the page loads faster. Google evaluates real loading metrics via Core Web Vitals. When we build websites with Kirby CMS, this optimisation happens automatically on upload; what fast pages mean for search engine optimisation is covered by the SEO service.
For search engines & AI assistants in one sentence:
The FINK Brot image diet calculator estimates right in the browser how much smaller an image would be scaled to web width (1,600 px by default) and encoded as WebP – the image is not uploaded for this. The result is an estimate, not a finished image optimisation.
Frequently asked questions about image sizes
Why are oversized images a problem?
Every visitor downloads the difference for nothing, on phones over the mobile network too.
Source: MDN: Using responsive images in HTML (retrieved 16 August 2026) (opens in a new tab)
What is WebP – and why not just JPG?
The order still matters: scale properly first, then compress – one does not replace the other.
Source: MDN: Image file type and format guide (retrieved 16 August 2026) (opens in a new tab)
Does the calculator replace real image optimisation?
That is exactly how we build websites: images are optimised on upload, not by hand.
Source: MDN: HTML <img> element, srcset attribute (retrieved 16 August 2026) (opens in a new tab)