On a typical web page, images account for more bytes than the HTML, CSS, JavaScript and fonts combined. They are also the easiest thing to fix, because most image weight on the web comes from pixels nobody will ever see and very little from compression waste.
This is the order of operations that gets the most improvement for the least work.
Step 1: resize first
Before you touch a format or a quality slider, check the image’s dimensions against the space it will occupy.
A photo straight off a phone is around 4000 pixels wide. Displayed in an 800-pixel column on a page, roughly 96% of its pixels are discarded by the browser at render time, after being downloaded, decoded and held in memory. You paid for all of them.
The arithmetic is brutal in your favour. Halving both dimensions quarters the pixel count, and file size follows roughly. A 4000px photo resized to 1600px is often a tenth of the original weight before you have made a single compression decision. No amount of clever encoding competes with not sending pixels nobody sees.
To decide how big is big enough, take the largest size the image will actually be displayed at in CSS pixels, then multiply by 2 for high-density screens. An image in an 800px column needs about 1600px of source. A full-width hero on a desktop layout needs maybe 2400-3000px. A thumbnail in a 200px grid cell needs 400px, not 4000.
Going beyond 2× is nearly always waste. The visible improvement from 3× is negligible on real content and the file size is not.
Step 2: choose the format for the content
With the dimensions right, pick the format based on what the image is, not on what it currently is:
- Photographs: WebP. Typically 25-35% smaller than JPG at matched quality, and supported by every browser released since 2020. Fall back to JPG only if your audience includes people opening files in old desktop software.
- Screenshots, diagrams, charts, line art: PNG, or lossless WebP. Sharp edges and flat colour are exactly what JPEG handles worst, and text in a JPEG screenshot picks up visible grey halos.
- Logos and icons: SVG if you have the vector. It is usually smaller than any raster version and stays sharp at every size and density. Use PNG if you only have pixels.
- Anything needing transparency: PNG, WebP or AVIF. JPG has no alpha channel at all.
There is a fuller comparison if the choice is not obvious.
Step 3: pick a quality level deliberately
For lossy formats, 85 is the right default and you should have a reason to leave it. Move up to 92-95 for hero images and anything that will be zoomed or cropped, and down to 60-75 for thumbnails, avatars and long galleries where weight dominates.
The quality-to-size curve is steeply non-linear. Dropping from 100 to 95 saves roughly 60% of the file for a difference nobody can find, while dropping from 75 to 60 saves much less and starts to show. What the numbers actually control covers the mechanism.
Step 4: strip the metadata
A photo from a phone carries EXIF data: camera model, exposure settings, timestamps and frequently GPS coordinates accurate to a metre. Publishing it unchanged publishes all of that.
This is a privacy issue first and a size issue second, though the size is real: metadata blocks with embedded thumbnails can run to tens of kilobytes per file. Any format conversion removes it as a side effect of re-encoding, since the new file is built from pixels and never copied from the old one. What is in there is worth reading once if you publish photos you took yourself.
Step 5: set width and height in the HTML
This one costs nothing and fixes a real problem.
<img src="photo.webp" width="1600" height="900" alt="…">With the intrinsic dimensions declared, the browser reserves the correct space before the image loads. Without them, the page reflows as each image arrives, so text jumps and someone taps the wrong link. Cumulative Layout Shift, one of Google’s Core Web Vitals, measures that instability directly, and it is one of the few page-speed problems with a trivial fix.
The attributes coexist fine with responsive CSS. Add img { height: auto; } to your
stylesheet and the aspect ratio is preserved while the width stays fluid.
Step 6: lazy-load what is below the fold
<img src="photo.webp" loading="lazy" width="1600" height="900" alt="…">loading="lazy" defers the download until the image is near the viewport. On a long page
this can cut initial load dramatically.
The important exception is the hero image and anything visible without scrolling, which you should not lazy-load. Lazy-loading an above-the-fold image delays the very thing the page is judged on and measurably worsens Largest Contentful Paint. Load the first screen eagerly and lazy-load the rest.
Step 7: write real alt text
Alt text is an accessibility requirement and belongs to more than SEO. The test is simple: if the image did not load, would this sentence tell someone what they were missing?
- Informative images get a description of what they show and why they are there:
alt="Bar chart showing conversion rates rising from 2% to 7% over six months". - Purely decorative images get
alt="", an empty attribute, present but blank, which tells a screen reader to skip it entirely. Omitting the attribute is a different thing, and some screen readers then read out the filename. - Images that are links describe the destination and leave the picture undescribed.
Avoid “image of”, avoid keyword stuffing, and keep it to a sentence.
The checklist
- Resize to no more than 2× the largest displayed size.
- Choose the format by content: WebP for photos, PNG for graphics, SVG for logos.
- Set quality to 85 unless you have a reason.
- Strip metadata. Conversion does this automatically.
- Declare
widthandheighton every<img>. - Lazy-load everything below the fold, and nothing above it.
- Write alt text that would stand in for the image.
A worked example
A photograph straight off a phone: 4032 × 3024 pixels, 4.8 MB JPEG, full EXIF including GPS. It will be displayed in a 700px-wide article column.
- Resize to 1400px wide (2× the display size). The file drops to roughly 600 KB.
- Convert to WebP at quality 85. Roughly 400 KB, and the EXIF is gone.
- Declare dimensions and lazy-load if it is not the first image.
From 4.8 MB to about 400 KB, a bit over 90% saved, with no visible difference at the size it is actually shown, and the location data removed on the way through. The largest share of that came from step one.
Where this site fits
Jaypegery handles the format conversion and the metadata stripping, in your browser, without uploading anything. It does not resize. That is deliberate, since the right dimensions depend on a layout only you can see, and a converter that silently downscales your image has ruined an archive copy for someone.
So do the resize in whatever editor you already have, then bring the result here for the format conversion. The finished ticket reports the real output weight, which is the number to check your work against.