How to Optimize Images for the Web

Images are usually the heaviest thing on a page and the easiest thing to fix. The work is four decisions in a fixed order — how many pixels, which crop, which format, how much quality — and this guide walks each one with real numbers.

What actually makes an image file big?

Pixel count, before anything else. An image is a grid: width multiplied by height. A photo straight off a modern phone at 4000 × 3000 holds 12 million pixels, and at 24 bits per pixel — eight bits each for red, green and blue — that is 36 million bytes, about 36 MB uncompressed.

That 8:1 the camera already achieved is the important context. A compressor cannot repeat that trick indefinitely — each additional halving costs visible quality. Removing pixels does not, provided the image is still larger than the space it occupies on screen. This is why the order of operations matters more than the choice of tool.

How wide should the image really be?

Twice the widest space it ever occupies on the page. Modern phones and laptops pack two physical pixels into every CSS pixel, so an image displayed 800 CSS pixels wide needs 1600 real pixels to look sharp. Beyond that the extra data is downloaded, decoded and thrown away.

The saving compounds because area scales with the square of the linear dimension. Dropping 4000 pixels wide to 1600 is a factor of 2.5 on each side, so 84% of the pixels are gone — 12 megapixels down to 1.92. That single step usually does more than everything else combined.

Crop before you resize where you can. Cropping deletes pixels you were never going to show, and it fixes the composition on your terms rather than letting a CSS rule cut the subject’s head off. Work out the matching width and height first so the crop lands exactly on the ratio your layout expects.

JPEG, PNG, WebP or AVIF — which format?

Match the format to the content, not to habit. Photographs have soft gradients and noise, which is exactly what lossy codecs handle well. Screenshots, logos and text have hard edges and flat colour, which lossy codecs handle badly and lossless codecs handle brilliantly.

One rule covers most cases: if it was photographed, use a lossy format; if it was drawn, use a lossless or vector one. A 1600-pixel screenshot of a code editor saved as JPEG will show coloured fringing around every letter, while as PNG it is both perfect and often smaller.

How much quality can you take away before it shows?

More than most people expect, and the curve is steep at the top. The numbers below are a worked example on one 1600 × 1200 photograph — your own files will differ with subject matter and noise, but the shape holds for any photo.

Going from 95 to 80 removes more than half the file and costs nothing you can see. Going from 80 to 60 removes another 120 KB and starts to cost something you can. That is the whole trade-off: work down from the top in steps of five, and stop at the first setting where you can see the difference at full size.

Worked example: 4.2 MB down to 190 KB

A photo straight off a phone, destined for a blog post where images display 800 CSS pixels wide. Each row is one tool and one decision.

4.2 MB to 190 KB is 95% smaller, about 22 times. Note where the saving came from: step 1 alone accounted for 3.64 MB of the 4.01 MB removed — 91% of the total. Steps 2 to 4 are worth doing, but they are refinements. If you only ever do one thing, resize.

How to optimize an image in your browser, step by step

All of these run in the page itself. The file is read into browser memory and never uploaded, which matters when the photo has a face or a location in it.

If the source came off an iPhone, do the conversion first: an HEIC file will not open in most editors, so convert it before anything else and work from the result.

Icons, logos and SVG: a different problem

Everything above assumes pixels. Logos, icons and diagrams are shapes, and shapes should stay shapes. An SVG stores instructions rather than a grid, so one file is sharp at 16 pixels and at 1600, on any screen density, and typically weighs a few kilobytes.

Two things are worth knowing. First, SVGs exported from design software carry a lot of editor junk — comments, unused definitions, absurd coordinate precision — and running them through an optimiser routinely removes 20–60% with no visual change. Second, tiny images can be embedded directly in your CSS or HTML as a base64 data URI, which removes a network request, but base64 encoding adds about 33% to the size. That is a good trade below roughly 4 KB and a bad one above it.

What should you strip before publishing?

EXIF metadata. Every photo from a phone or camera carries a block describing how it was taken: model, lens, shutter, aperture, ISO, timestamp, an embedded preview thumbnail, and on a phone usually GPS coordinates accurate to within a few metres. Publishing a photo taken at home publishes your address with it.

Stripping it is one pass and saves 10–20 KB per file into the bargain. Keep the metadata only when it is the point — a photography portfolio where shutter and aperture are part of the story, or an image whose colour profile matters for print.

Where the subject matter itself is sensitive rather than the metadata, blur or block it out before publishing rather than relying on the viewer not to look closely. Pixelation applied to a whole face is reversible only in fiction, but a light blur over a licence plate or a document number is not always enough — use a solid block for anything that must not be recovered.

What changes when the target is print?

The constraint flips. On screen you match pixels to a CSS width; in print you match pixels to physical inches at a given density. The standard is 300 PPI for photographic printing, and the arithmetic is one division:

printed inches = pixels ÷ PPI

So the 1600 × 1200 web export prints cleanly at only 5.3 × 4 inches. The original 4000 × 3000 file prints at 13.3 × 10 inches at the same density — which is the reason to keep originals rather than only the web copies. At 150 PPI, acceptable for posters viewed from a distance, both numbers double.

Image terms, defined

Lossy compression

Discards information permanently to reach a smaller file. JPEG, WebP and AVIF are lossy. Repeated saves compound the damage.

Lossless compression

Reconstructs the original pixels exactly. PNG is lossless, which is why it is right for screenshots and wrong for photographs.

Chroma subsampling

Storing colour at half the resolution of brightness, usually written 4:2:0. The eye barely notices on photographs, but it is what makes coloured text look fringed in a JPEG.

Device pixel ratio (DPR)

How many physical pixels a screen uses per CSS pixel. Most phones and modern laptops are 2 or 3, which is why an image is exported at twice its display width.

EXIF

The metadata block inside a photo: camera, settings, timestamp, thumbnail and often GPS location.

PPI and DPI

Pixels per inch describes an image; dots per inch describes a printer. In everyday use they are treated as the same number, and 300 is the photographic standard.

Alpha channel

Per-pixel transparency. PNG, WebP, AVIF and SVG have it; JPEG does not, which is why a logo saved as JPEG arrives with a white box behind it.

Largest Contentful Paint (LCP)

The Core Web Vitals metric that times how long the biggest element on screen takes to appear. On most pages that element is an image, and 2.5 seconds or less counts as good.

Frequently asked questions

What makes an image file big?

Pixel count first, quality second. A 4000 × 3000 photo holds 12 million pixels, about 36 MB uncompressed at 24 bits each. Compression shrinks that, but it can only work with the pixels you give it — which is why resizing saves far more than any quality slider.

Should I resize or compress first?

Resize. Halving width and height removes 75% of the pixels and every later step then works on a quarter of the data. Squeezing a full-resolution photo into a small file forces visible artefacts; a resized image at the same file size still looks clean.

Is WebP better than JPEG?

For the web, usually. WebP runs about 25–35% below JPEG at matching quality, supports transparency and animation, and works in every current browser. JPEG remains the safer choice for files that will be emailed, printed or opened in older desktop software.

What JPEG quality should I use?

Around 80. In the example above, quality 80 produced 310 KB against 560 KB at quality 92 with nothing visible lost. Below 70 fine texture softens; below 60 ringing appears around hard edges and text.

How wide should an image be for a website?

Twice its displayed width. An image shown at 800 CSS pixels should be exported at 1600. Anything beyond that is downloaded, decoded and discarded by the browser.

Do images affect SEO?

Indirectly but strongly. Images are usually both the largest contributor to page weight and the element Largest Contentful Paint measures, and Google treats an LCP at or under 2.5 seconds as good. Descriptive filenames and alt text help image search on top of that.

Why will my iPhone photo not upload?

It is probably HEIC. iPhones save in that format by default and most browsers and Windows applications cannot read it. Convert to JPEG for maximum compatibility, or to PNG if the image has transparency or sharp graphics worth preserving.

Does optimizing an image in the browser upload my file?

Not with these tools. They read the file into browser memory and process it in the page, so nothing leaves your device. The trade-off is that your own CPU does the work, so very large batches are slower than a server would be.

All the tools used in this guide

Authoritative sources

• Choose the right image format — web.dev
• Image file type and format guide — MDN Web Docs
• Google Images SEO best practices — Google Search Central
• Largest Contentful Paint and the 2.5 second threshold — web.dev
• WebP — Wikipedia
• Exif metadata — Wikipedia

Last updated: 2026-08-10 · Published: 2026-08-10 · Written by the miniwebtool.com editorial team.

File sizes, quality settings and percentage savings in this guide are worked examples from one representative photograph, used to demonstrate the method; your own results will vary with subject matter, noise and the encoder you use. Browser support and platform image specifications change without notice — confirm current requirements with the service before an important upload. This article is educational and does not constitute technical advice for any specific publishing workflow.