How to Resize Images for a Faster Website

Published August 12, 2026

If a page on your site feels slow, images are the first thing to check — and the fix is usually embarrassingly simple. Most slow pages aren't slow because of code or hosting. They're slow because someone dropped a 4032×3024 photo straight off a phone into a slot that displays it 800 pixels wide. The visitor downloads five megabytes so their browser can shrink it and throw 96% of the pixels away.

This guide covers the part people get wrong: what width your images actually need, why resizing beats compression, and how to check whether it worked. No plugins, no build tools, no uploads.

The mistake almost everyone makes

Here's the crucial thing about how browsers work: the browser downloads the entire image file first, then scales it to fit your layout. Setting width="800" in your HTML, or max-width: 100% in CSS, changes only how the picture is drawn. The download is exactly the same size either way.

So an image that looks perfectly small on screen can still be a 5 MB file. On a fast laptop connection you'd barely notice. On a phone on mobile data — which is how most people will see your site — it's several seconds of blank space, and those seconds are exactly what Google's Core Web Vitals measure. Largest Contentful Paint, the metric that most often fails, is usually an image.

The only real fix is to make the file physically smaller before you upload it. That means resizing the pixel dimensions.

Why resizing beats compressing

People reach for a compressor first because it's the more familiar word, but resizing is far more powerful. The reason is that pixel count grows with the square of the width:

• 4000×3000 = 12 million pixels
• 2000×1500 = 3 million pixels (half the width, a quarter of the data)
• 1000×750 = 0.75 million pixels (a sixteenth of the original)

Halving an image's width removes roughly 75% of its weight and, if it's displayed at that size anyway, costs you nothing visually. Compression alone might save 40–60% on a good day and always trades away some quality. The right order is: resize first, then compress — that way you're not spending effort compressing pixels you were about to discard.

What width do your images actually need?

The honest answer is "as wide as the space they fill, times two". The doubling accounts for high-density screens — Retina displays and modern phones pack two or three physical pixels into each CSS pixel, so an image drawn 800 pixels wide looks noticeably crisper if the file is 1600 wide.

Practical targets that work for almost every site:

• Full-width hero / banner: 1600–2000 px wide
• Blog body image: 1200–1600 px wide
• Half-width or two-column image: 800–1000 px wide
• Card or grid thumbnail: 600–800 px wide
• Sidebar / avatar / logo: 200–400 px wide
• Product gallery main shot: 1200–1600 px (leave the zoom original separate)

Beyond about 2000 pixels wide you are almost always paying for detail nobody will ever see. If you're unsure which bucket an image falls into, right-click it on your live page, choose Inspect, and look at the displayed size the browser reports — then double that number.

How to resize a batch of images for the web

The Toolyard Image Resizer handles multiple files at once, which matters when you're fixing a whole page or a product catalogue.

1. Open the resizer and drag in every image you want to fix — you can drop a whole selection at once.
2. Set Resize by to Max width & height.
3. Type your target, for example 1600 × 1600. Every image is scaled to fit inside that box while keeping its own aspect ratio, so portraits and landscapes both come out sensibly.
4. Set Output to WebP for the biggest saving, or leave it on JPG if your platform doesn't accept WebP.
5. Click Download all and re-upload the resized set to your site.

Using a max-box rather than a fixed width is the key trick for batches: you never have to sort your images by orientation, because nothing ever ends up larger than the limit in either direction.

Then compress — but only after resizing

Once the dimensions are right, a compression pass squeezes out what's left. Run the resized files through the image compressor at around 75–80% quality. For photographs that's essentially invisible on a screen and typically halves the file again.

As a rule of thumb for what "good" looks like after both steps: a full-width hero photo should land around 150–250 KB, a body image 80–150 KB, and a thumbnail 20–50 KB. If any image on your page is over half a megabyte, it's worth another look.

Pick the right format while you're at it

Since you're already re-saving each file, choose the format deliberately:

• WebP — the default choice in 2026. Typically 25–35% smaller than JPG at matching quality, supported everywhere current.
• JPG — photos, maximum compatibility, anywhere WebP isn't accepted (some older CMS uploaders, some email clients).
• PNG — only for transparency, screenshots of text, or flat graphics with hard edges. PNG photos are enormous; never use it for a photograph.
• SVG — logos, icons and simple illustrations. Infinitely sharp at any size and usually only a couple of kilobytes.

One caution: switching a logo or icon from SVG to a resized PNG is a step backwards. Keep vector art as vector art.

Two extra habits that cost nothing

Add loading="lazy" to images below the fold. The browser then postpones downloading them until the visitor scrolls near, so your first screen renders faster. Never put it on your hero image — that's the one you want loaded immediately.

Set width and height attributes on every image tag. The browser reserves the right amount of space before the file arrives, so your text stops jumping around as the page loads. That jumping is Cumulative Layout Shift, another Core Web Vitals metric, and this one-line habit fixes most of it.

How to check it worked

Reload your page, open your browser's developer tools (F12), go to the Network tab and filter to Img. You'll see the real transferred size of every image and the total at the bottom. Aim to get a typical page's images under about 1 MB combined. Then run the page through Google's PageSpeed Insights and check whether the "Properly size images" and "Largest Contentful Paint" warnings have gone.

It's the rare kind of optimisation where the before-and-after is unmistakable: pages that took four seconds routinely drop under one, with no visible difference to the images themselves.

Is it private and free?

Yes. The Toolyard resizer and compressor both work entirely inside your browser — your images are read, resized and saved on your own device, and are never uploaded to any server. That means no queue, no file-size cap, no account, and no watermark on the result. It's a genuine advantage for unreleased product photos or client work: the files simply never leave your computer.