Resize an image

Shrinking is safe, enlarging is not

These two operations look symmetrical and are not. When you shrink an image, every pixel in the result is an average of several real pixels from the original — there is more information available than the output needs, and the only question is whether the tool uses it properly. This one reduces through repeated halving rather than a single large jump, because one big draw samples far too few of the source pixels and produces the jagged, shimmering edges that make a reduced photo look cheap.

Enlarging has no such luxury. The detail is not there to recover, so every added pixel is interpolated from its neighbours, and the result is inevitably softer than the original was at its own size. It is sometimes the right call — a logo that needs to fill a header, an image being printed small — but it is never free, which is why the enlarging switch is off until you turn it on rather than something you trip over by typing a big number.

Proportions, and when to break them

With keep proportions on, filling in one dimension derives the other from the original's aspect ratio, and filling in both fits the image inside the pair — it touches whichever bound is tighter and leaves slack against the other. That is almost always what you want, and the dimensions row names the bound that did the limiting so a number that appears to have been ignored can be seen doing nothing instead.

Turning it off makes both numbers literal, stretching the image to match. This distorts faces and circles immediately and obviously, so it is worth reserving for the cases that genuinely call for it: a background texture, a banner slot with a fixed shape, or an image that was stored squashed and needs correcting back.

Picking a size

• Full-width photo — 1920px on the long edge. Larger sends pixels that no ordinary screen will display.
• Article or content column — 800 to 1200px, depending on how wide your layout runs.
• Thumbnail or avatar — 300 to 400px is plenty.
• Email — 600px wide is the traditional safe maximum, and many clients still assume it.

Phones complicate this. A high-density screen packs two or three physical pixels into every CSS pixel, so an image displayed in a 400px-wide slot on a modern phone wants around 800 real pixels to look sharp. Doubling your intended display size is a reasonable default, and going beyond triple is wasted bandwidth.

AVIF and JPEG XL, and what they do for search

AVIF is a still-image format built from the AV1 video codec. At the same visual quality it typically comes in around half the size of a JPEG and noticeably smaller than WebP, it carries transparency, and it can hold HDR and wide-gamut colour. Its cost is on the other side: it is slow to encode, and at very low quality settings it smooths fine texture away rather than producing JPEG's blocky artefacts. Every current browser displays it, and Google Search has indexed it since 2024.

JPEG XL is the newer format, designed as a long-term successor to JPEG. It compresses about as well as AVIF on photographs and better on very high-quality images, supports lossless and lossy modes in one format, loads progressively so a coarse version appears before the whole file arrives, and is the only modern format that can repackage an existing JPEG about 20% smaller and convert it back again bit-for-bit. Browser support has been the obstacle: Safari has decoded it since 2023, while Chrome dropped an experimental decoder that year and has only recently brought it back. Google's list of image formats it indexes for Search does not include it.

Neither format is a ranking factor in itself — Google has been explicit that picking AVIF earns no bonus. What they change is weight. The largest image on a page is very often what sets its Largest Contentful Paint, one of the Core Web Vitals Google uses as a page-experience signal, and a hero image that is half the bytes arrives sooner on a slow phone connection. The smaller page also loads faster for every visitor, which matters for how long people stay whether or not a search engine is watching.

The practical recipe for a web page is the same for both:

• Resize first. No format rescues an image sent at four times the size it is displayed. Get the pixel dimensions right, then pick the format.
• Use AVIF as the main format for photographs, with a JPEG or WebP fallback in a <picture> element for older browsers.
• Offer JPEG XL as an extra source, listed first in the <picture>, rather than as the only file — browsers that cannot read it skip it and fall through to the next source.
• Keep the filename and alt text. A format switch that renames blue-widget.jpg to blue-widget.avif changes the image's URL; redirect the old one, and keep the alt text describing the image, which counts for far more in image search than the format does.
• Set width and height on the image tag from the dimensions this page reports, so the browser reserves the space and the layout does not jump when it loads.

What resizing removes

The image is decoded, redrawn onto a canvas, and re-encoded, which means everything that was not pixel data is discarded: camera and lens information, exposure settings, capture timestamps, and — the one that matters most — any GPS coordinates the camera embedded. If you are about to post a photo taken at home, that is a privacy win worth having. If you were relying on the capture date to sort your archive, keep the original.

Wanting a smaller file rather than smaller dimensions? The compressor holds the size and squeezes the bytes. Changing format is on the converter, and the favicon page handles the specific sizes a site icon needs.

Common questions

Will resizing make my image blurry?

Shrinking, no — done properly it is close to lossless in appearance. This page reduces through repeated halving rather than one large jump, which averages every source pixel into the result; a single big draw skips most of them and produces the jagged, sparkly edges that make a reduced image look cheap. Enlarging is the opposite story. There are no extra details to recover, so an upscale invents pixels by interpolating between the ones you have, and the result is always softer than the original at the same size. That is why enlarging is off until you switch it on.

How do I resize to an exact width and height?

Enter both, then turn off "keep proportions". With proportions locked, giving both numbers fits the image inside them — it touches one bound and leaves slack against the other, so nothing is distorted. Unlocked, both numbers are obeyed literally and the image stretches to match, which is occasionally what you want for a banner or a fixed-size slot and is usually not. The dimensions row tells you which of the two bounds actually constrained the result, so a number that looks ignored can be seen doing nothing rather than being silently dropped.

Why is my resized file bigger than the original?

Usually because the original was a heavily compressed JPEG and the output is PNG, which is lossless and stores every pixel exactly. Re-encoding a photo as PNG routinely multiplies the file size several times over even at a smaller pixel count. Switch the output format to JPEG or WebP and the size will drop below the original. It can also happen when you enlarge, since more pixels means more data no matter how efficient the format is.

Should I use AVIF or JPEG XL for my website?

AVIF, for now. Every current browser displays it, and Google Search indexes it, so an AVIF photo can stand alone in an img tag. JPEG XL is the better format on paper — it is lossless-capable, decodes progressively, and can repackage an existing JPEG about 20% smaller without touching a pixel — but browsers have been slower to support it and Google's list of indexable image formats does not include it. If you use JPEG XL, serve it from a picture element with an AVIF or JPEG fallback, so that a browser or crawler that cannot read it gets an image it can.

Why does AVIF or JPEG XL take longer than the other formats?

Because your browser cannot write either one itself. JPEG, PNG, and WebP are encoded by the browser's own canvas in a few milliseconds. AVIF and JPEG XL are encoded by the open-source Squoosh codecs compiled to WebAssembly, running in a background thread on your device. AVIF in particular trades encoding time for file size: it searches hard for the smallest file at a given quality, and on a large photo that takes a second or more. The encoder is downloaded the first time you pick the format, not before, and nothing is uploaded either way.

Does resizing strip EXIF data?

Yes, and that is worth knowing in both directions. Because the image is redrawn onto a canvas and re-encoded, everything that was not pixels — camera model, lens settings, timestamps, and GPS coordinates — is gone from the output. That is a privacy benefit if you are about to post a photo taken at home, and a real loss if you were relying on the capture date. Keep the original if the metadata matters.

What size should I use for a web page?

For a full-width photograph, 1920px on the long edge is the usual ceiling — beyond that you are sending pixels no ordinary screen will show. A content-column image is typically 800–1200px, a thumbnail 300–400px. The one thing worth accounting for is that phones have high-density screens, so an image displayed at 400 CSS pixels on a modern phone wants roughly 800 real pixels to look sharp. Halving your display size and doubling it back is a reasonable rule.

Is my image uploaded anywhere?

No. Decoding, resizing, and re-encoding all happen in your browser, using canvas and WebAssembly, and the file never leaves your device. Nothing is sent to a server, nothing is stored, and the page keeps working with the network disconnected once it has loaded — except that the AVIF and JPEG XL encoders are fetched the first time you choose one of those formats.