Image File Size Estimator

Why image file size matters before you export

Every image on a website, in an email, or in a presentation carries a file size, and that size decides how fast the page loads, how much storage it consumes, and how much mobile data it costs your audience. A single uncompressed photograph from a modern camera can exceed twenty megabytes, which is fine on a local drive but punishing on a web page, where several such images can push a page past a hundred megabytes and drive visitors away before anything appears. Estimating file size from dimensions and format before you export lets you make informed trade offs: a smaller dimension, a more efficient format, or a slightly higher compression setting can cut a file to a tenth of its size with no visible loss, and that difference compounds across every image on a site.

The relationship between dimensions and file size is direct but not linear in the way people expect. Doubling both width and height quadruples the pixel count, so a 4000 by 3000 photograph has four times the pixels of a 2000 by 1500 version, and roughly four times the file size at the same quality. Halving the dimensions is therefore the single most effective way to shrink an image, far more effective than fiddling with quality settings. This is why responsive images matter: serving a 4000 pixel wide photograph to a phone screen that displays it at 400 pixels wastes ninety percent of the data, and generating smaller versions for smaller screens is one of the highest-impact performance optimisations any site can make.

How the estimator works

The estimator starts from the pixel count, which is width multiplied by height, and from the uncompressed size, which for a typical colour photograph is three bytes per pixel, one each for red, green, and blue. It then applies a compression factor for the chosen format, representing how much of that raw data survives typical compression for photographic content. JPG keeps roughly ten percent of the raw size, WebP about eight percent, GIF about twenty five percent, and PNG about forty five percent, because PNG is lossless and preserves every detail. The result is rounded to whole kilobytes, with a megabyte figure alongside, and a comparison across all four formats so you can see the trade off at a glance. These are estimates for typical photo content, not guarantees: a flat illustration with large areas of solid colour compresses far smaller in PNG, while a noisy night photograph compresses larger in JPG.

Understanding that content matters is essential to using estimates well. A photograph of a clear sky compresses beautifully, because large areas share similar colours, while a photograph of dense foliage or a crowd compresses poorly, because almost every pixel differs from its neighbours. Screenshots with sharp text and flat colours behave differently again: they compress well as PNG, because the lossless format preserves crisp edges, but poorly as JPG, which introduces visible artefacts around text. The estimator's factors assume photographic content, so treat the numbers as a planning guide and check the real exported file before publishing anything critical. If your image is a graphic rather than a photograph, expect PNG to beat the estimate and JPG to look worse than the estimate suggests.

Choosing the right format

JPG remains the default for photographs because it is universally supported, produces small files, and handles smooth colour gradients well. Its weakness is that it is lossy: every save discards some detail, and repeated saves degrade quality, so always keep an original and export JPG copies from it rather than re-saving a JPG. PNG is the right choice for graphics, logos, screenshots, and any image that needs transparency, because it is lossless and preserves sharp edges exactly. Its weakness is file size for photographs, where it can be five times larger than JPG for the same image. WebP combines the best of both for modern browsers, offering lossy compression smaller than JPG and lossless compression with transparency, and it is now supported widely enough to be a safe default for the web, with a JPG fallback for very old browsers if you need one.

GIF survives mainly for simple animations, where its limited palette of 256 colours and its animation support still have no simpler alternative, though modern video formats and animated WebP have largely replaced it for larger animations. For still images, GIF is rarely the best choice today: it produces larger files than PNG for most graphics and much worse quality for photographs. A newer format, AVIF, compresses even smaller than WebP for photographs, but its encoding is slower and its support, while growing, is not yet universal, so it is best used as an enhancement rather than a sole format. The practical workflow for most sites is WebP first, JPG as a fallback, and PNG only for graphics that demand lossless quality or transparency.

Dimensions, resolution, and display size

People often confuse pixel dimensions with resolution, measured in dots per inch, but for screens only pixel dimensions matter. A 2000 pixel wide image displays at 2000 pixels regardless of whether its metadata claims 72 or 300 dots per inch, and the dots-per-inch figure only matters when printing, where it determines the physical size. For the web, the question to ask is how large the image will display: an image shown at 800 pixels wide needs at most 1600 pixels of source for sharp display on high-density screens, which show two device pixels per CSS pixel, and anything beyond that is wasted data. Serving two or three sizes, such as 800, 1200, and 1600 pixels, and letting the browser pick, covers nearly every screen without waste.

High-density displays, often called retina screens, are the reason for the doubling rule, but doubling beyond two times is rarely worthwhile, because the human eye cannot resolve the extra detail at normal viewing distances, and the file size penalty is severe. A hero image displayed at 1200 pixels wide can be served at 2400 pixels for retina sharpness, but serving it at 4800 pixels quadruples the file size for no visible benefit. The estimator helps here by showing how quickly size grows with dimensions, so you can see that the jump from 1200 to 2400 pixels quadruples the estimate, and decide whether the sharpness gain justifies it. In most cases, a well-compressed 1600 pixel image looks better on the web than a poorly compressed 4000 pixel one, because compression artefacts are more visible than a modest resolution shortfall.

Practical ways to shrink images

Start by resizing to the display size, or at most twice it for retina screens, before touching any other setting. Next, choose the efficient format: WebP for photographs and graphics on the web, JPG as a fallback, PNG only where lossless quality or transparency is required. Then adjust quality: for JPG and WebP, a quality setting of 80 to 85 is visually indistinguishable from 100 for most photographs while cutting the file roughly in half, and dropping to 70 is often acceptable for thumbnails and background images. Strip metadata, such as camera settings and location data, which can add tens of kilobytes and raise privacy concerns, and consider converting photographs to the sRGB colour space, which is the web standard and avoids colour shifts on different screens.

For sites with many images, automation beats manual effort. Build tools can generate multiple sizes and formats at deploy time, content delivery networks can resize and convert on the fly, and lazy loading ensures that images below the fold do not download until the user scrolls to them, which improves perceived speed even when total size is unchanged. A simple budget helps too: aim for each page's total image weight under one megabyte where possible, and under two megabytes at most, and treat any single image over 500 kilobytes as a candidate for resizing or recompression. The estimator gives you the numbers to set that budget before you export, rather than discovering the problem after the page is live.

Common mistakes

The most common mistake is uploading camera originals directly to a website, complete with 6000 pixel dimensions and embedded location data. The second is saving a JPG, opening it, and saving it again, which compounds compression artefacts each time. The third is using PNG for photographs, which produces enormous files for no visible benefit. The fourth is the opposite: using JPG for a logo or screenshot, which surrounds sharp edges with visible halos. The fifth is forgetting about thumbnails and social previews, which often need their own smaller versions rather than the full-size original scaled down by the browser, a practice that downloads the full file anyway. Each of these mistakes is easy to make and easy to fix once you estimate before you export.

• Resize to display size, or twice it for retina, before anything else.
• Use WebP for the web, JPG as a fallback, PNG only for graphics and transparency.
• Quality 80 to 85 is visually near-perfect for most photographs and halves the file.
• Strip metadata and convert to sRGB before publishing.
• Budget total page image weight under one megabyte where possible.

Estimate first, export second, and check the real file before publishing, and your images will load fast, look sharp, and cost your audience far less data than the camera originals ever would.