Guides / Finipix / Editing pages
Web Image Formats and Sizes: JPG, PNG, WebP, AVIF
Finipix guide · Resize and compress images for the web. Open Finipix
A single photo straight off a phone is often 3 to 6 MB and 4000 pixels wide. Drop three of those into a landing page and a visitor on mobile data waits several seconds for pictures that are shown at 400 pixels wide anyway. Images are the usual reason a one-page site is slow, and most of the fix happens before the file goes into your HTML: pick a suitable format, resize to the size you actually display, and compress.
Which format for which image
| Format | Good for | Avoid for |
|---|---|---|
| JPG (JPEG) | Photos and anything with smooth gradients | Text, logos, sharp edges, transparency |
| PNG | Screenshots, flat graphics, images that need a transparent background | Large photos (files get very big) |
| WebP | Photos and graphics alike; supports transparency and animation, usually smaller than JPG or PNG | Very old browsers |
| AVIF | Photos where you want the smallest file; often beats WebP | Cases where you cannot provide a fallback |
| SVG | Logos, icons, simple illustrations; stays sharp at any size | Photos |
| GIF | Short, simple animations when nothing else is available | Photos and long animations (WebP or a video is far smaller) |
On browser support: JPG, PNG, GIF and SVG work everywhere. WebP is supported by the current versions of Chrome, Edge, Firefox and Safari, though older Safari releases on older macOS versions do not show it. AVIF arrived later in each browser, so MDN still recommends offering a WebP, JPG or PNG fallback. The <picture> element does that: the browser takes the first source it understands.
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" width="1600" height="900" alt="Team at the spring workshop"> </picture>
For a small site, a single well-compressed WebP or JPG is also a reasonable choice.
Pixel dimensions: size for how it is shown
The question to ask is "how wide is this image on screen at most?" A photo that sits in an 800-pixel-wide column never needs to be 4000 pixels wide. Phones, many laptops and some monitors have high-density screens where one CSS pixel is drawn with two or more physical pixels, so the usual rule is to export at about twice the displayed width. Beyond 2x, the extra detail is hard to see and the file keeps growing.
- Hero or full-width banner: 1600 to 2000 pixels wide covers most laptop screens. Going to 2400 or more only pays off if the image is the whole point of the page.
- Content images inside a text column: if the column is 700 to 800 pixels wide, export at 1400 to 1600.
- Cards and thumbnails: shown at 300 to 400 pixels, export at 600 to 800.
- Logos: use SVG if you have it. If you only have a PNG, export it at twice the height it appears in the header, for example 80 pixels tall for a 40-pixel logo.
To let the browser choose between a 1x and a 2x file, use srcset: <img src="team-800.jpg" srcset="team-1600.jpg 2x" alt="…">. For most small pages, a single 2x file is simpler and good enough.
File sizes worth aiming for
There is no official limit. These rules of thumb keep a one-page site quick on mobile data:
- Hero image: under about 200 to 300 KB.
- Content photos: under about 100 to 150 KB each.
- Thumbnails and icons: a few tens of KB at most; SVG logos are often under 10 KB.
- The whole page, images included: try to stay around 1 to 2 MB.
On a mobile connection every megabyte is a noticeable wait, and visitors on capped data plans pay for it. The hero image is often the largest element on screen when the page first appears, so a heavy one delays the moment the page looks finished. Google also measures this loading experience (its Core Web Vitals include Largest Contentful Paint) when it assesses pages.
How to compress, for free
Squoosh (squoosh.app), an open-source project from Google Chrome Labs, runs in the browser and states that images never leave your device. Open a photo, set the width under the resize option, pick an output format such as WebP or MozJPEG, and drag the divider to compare the original and the result side by side. A quality setting around 70 to 80 is a sensible starting point for photos; lower it until you can see the difference, then go back up a step.
For a whole set of images, Finipix, a free tool from Qorlize, does the same in the browser without uploading anything. Drop in many files at once, choose a width preset such as 1200 or 1920 pixels, an output format (JPEG, WebP or PNG) and a quality between 40 and 95, then download the results one by one or as a ZIP. It shows the size saved for each file and a before/after slider; making images smaller for the web walks through it.
Most image editors, free or paid, also have an export option with a resize step and a quality slider, and command-line tools pay off if you process many images at once. Whatever you use, the order is the same: resize, compress, then check the result at its real display size.
The HTML attributes that matter
width and height. Writing the image's pixel dimensions on the tag, like width="1600" height="900", lets the browser work out the aspect ratio before the file arrives and reserve the space. Without them, text jumps down when each image finishes loading, which is irritating to read and is exactly the "layout shift" that performance reports flag. The attributes do not stop the image from being responsive: CSS such as max-width: 100%; height: auto; still scales it down to fit.
alt. Describe what the image shows for people who cannot see it, and for when the file fails to load: alt="Two staff members assembling a display stand", not alt="image1". If the image is purely decorative, use an empty alt="" so screen readers skip it. Do not leave the attribute out entirely.
loading="lazy". This tells the browser to wait until the image is close to the visible area before downloading it. Use it on images further down the page. Do not use it on the hero image or anything visible when the page first opens; web.dev specifically advises against lazy-loading images likely to be in the first viewport, because it delays them.
<img src="images/workshop.webp" width="1400" height="933"
loading="lazy" alt="Participants testing the prototype at a long table">
Swapping in the smaller file
Once you have compressed images, they still have to replace the heavy ones in the page. In a text editor such as VS Code, change each src to the new file name and update width and height to match the new dimensions.
In Finipage, open the HTML file, then drag the new image file from your folder and drop it onto the image in the page; it is replaced in place. Or select the image and use Replace image in the properties panel on the right. To make an image fit its column instead of overflowing on small screens, set its width to 100% (or auto) in the Size section and leave the height on auto so the proportions hold. Then switch the preview to the Mobile width at the top to check it.
Two things to know about that swap. First, a replaced image is written into the HTML file itself as a data URL rather than kept as a separate file, so the HTML grows by roughly the image's size plus a third (the cost of Base64 encoding), and the editor warns you when the file is over 2 MB. Second, Finipage does not crop or compress images. Do the resizing and compression in Finipix, Squoosh or an image editor first; whatever file you drop in is what ends up in the page. If you want images to stay as separate files under an images folder, edit the src in a text editor instead.
Next steps
If an image appears in the editor but not after you move the file, the guide on missing images walks through the path problems. To confirm the lighter page actually behaves on a phone, see checking a page on mobile.
Want to try it on your own images? Open Finipix. It runs in your browser and your images stay on your device.