Skip to content
← Code Tools

File Size Estimator

Predict image output size in KB or MB from dimensions, format, and compression

Image File Size Estimator (KB/MB from Dimensions and Format)

There are good reasons to know how big an image will be before you encode it: the Core Web Vitals LCP budget on a landing page sets a ceiling on the hero image, CDN bandwidth costs scale with bytes served, and an image content management system needs to validate uploads against per-asset caps. This tool gives a fast estimate from three inputs that are usually known up front (pixel dimensions, target format, target quality), based on published bits-per-pixel rates for representative content. It is meant for planning, not for replacing the actual encoder when bytes need to be exact.

Bits Per Pixel by Format

The four common output formats have characteristic bits-per-pixel rates for photographic content. JPEG at quality 75 sits around 1.5 bits per pixel; at quality 85 around 2.2 bits per pixel; at quality 90 around 3.0 bits per pixel. PNG depends almost entirely on the content — a photo encoded as PNG-24 is typically 12 to 16 bits per pixel (lossless), while a flat-color graphic at PNG-8 might be 1 to 2 bits per pixel. WebP at quality 75 sits around 1.0 bits per pixel (roughly 30% smaller than JPEG at the same perceptual quality). AVIF at quality 60 sits around 0.5 to 0.7 bits per pixel (another 30 to 50% improvement over WebP). The tool uses these published averages, scaled by the width-times-height pixel count, to produce a size estimate.

Why It Is an Estimate, Not an Exact Number

The real encoder output depends on the actual content. A photo of a busy outdoor scene with lots of detail will encode larger than a photo of a uniform blue sky at the same dimensions and quality setting. A graphic with hard edges and flat colors will encode smaller as PNG than as JPEG. The tool uses bits-per-pixel rates representative of typical photographic content (the dominant case for the formats listed), so for that case the estimate is usually within 20 to 30 percent of what the actual encoder would produce. For unusual content (uniform color blocks, text-heavy graphics, line art), the actual result can differ significantly — use the tool for budgeting and the real encoder for the final bytes.

Planning an LCP Budget

The most common reason to estimate image size up front is to fit within the Core Web Vitals LCP (Largest Contentful Paint) budget on a landing page. A hero image at 1920x1080 in JPEG quality 85 is around 1920 * 1080 * 2.2 / 8 = 570KB by this tool's estimate, which is too large for a fast LCP on a mid-range mobile connection. Switching the same image to WebP at quality 75 drops the estimate to around 260KB — enough headroom that the LCP budget is realistic. Switching further to AVIF at quality 60 drops it to around 160KB. The tool lets you compare all four format-quality combinations side by side, which is the right framing for the LCP-budget decision.

CDN Bandwidth and Image Cap Planning

For CDN cost projection at a given monthly impression count, the per-image average size times the impression count times the cost-per-gigabyte gives a rough bandwidth bill. The tool helps in the format-selection step: a switch from JPEG quality 85 to WebP quality 75 across all images on a high-traffic site can cut the image bandwidth roughly in half, which is the kind of savings that pays for the engineering effort to add format negotiation to the asset pipeline. The same calculation works in the other direction for per-upload validation: if your application caps images at 1MB, the tool tells you which combinations of dimensions and quality stay under that cap and which require dimensional or quality compromises.

This tool plans the encode; Advanced Image Optimizer performs it, Image Converter handles the format switch alongside, and SVG Optimizer picks up the vector case where bits-per-pixel does not apply. Use the estimator to set the target, then use the optimizer to hit it.

Frequently Asked Questions

Is anything uploaded to a server?+
No. The tool runs a pure-math calculation in your browser. No file is ever uploaded — in fact, no file is ever needed; the inputs are just the dimensions, format, and quality you type or pick. The Network tab confirms no outbound calls during estimation.
How accurate is the estimate?+
For typical photographic content it is usually within 20 to 30 percent of the actual encoder output. The accuracy depends on how representative the content is: a busy outdoor photo, a portrait, a landscape — all encode close to the published bits-per-pixel rates the tool uses. Unusual content (uniform color, text-heavy graphics, line art) can encode significantly smaller (for those cases) or differently than the estimate suggests.
Which formats are supported?+
JPEG (qualities 60 through 95 in 5-point steps), PNG (8-bit indexed, 24-bit lossless, with and without alpha), WebP (qualities 50 through 90 lossy, and lossless mode), and AVIF (qualities 40 through 80). These cover the four formats that dominate modern web delivery. GIF is not included because for photographic content it is never the right choice; for animated GIFs, the size depends on frame count and the static estimate is not useful anyway.
Does it account for image metadata (EXIF, ICC profiles)?+
It assumes metadata is stripped, which is the common posture for web-delivery images. If your pipeline preserves metadata, add an overhead of 8 to 64KB per image (depending on what is preserved) to the estimate. EXIF camera metadata is typically a few hundred bytes; ICC profiles for color-managed images can be tens of kilobytes.
Why does PNG show such a wide size range?+
PNG compresses by run-length and predicted-pixel encoding, so the output size is highly content-dependent. A photographic PNG is typically 12 to 16 bits per pixel; a flat-color graphic might be under 1 bit per pixel. The tool shows the typical-photographic estimate by default and notes the wide range; for graphics-heavy content the actual encoder is the only reliable answer.
How does WebP compare to JPEG at the same quality number?+
Roughly: WebP at quality Q is perceptually similar to JPEG at quality Q + 5 to Q + 10, and around 25 to 35 percent smaller. The tool uses bits-per-pixel rates that reflect this — setting WebP at quality 75 gives a smaller estimate than JPEG at quality 75 because they are not at the same perceptual quality at the same number. Comparing WebP quality 75 to JPEG quality 85 is closer to apples-to-apples.
Can I estimate the size of an animated WebP or animated AVIF?+
Not directly. The static estimate is per-frame, so an animation is roughly frame-count times the per-frame estimate, with a small reduction (10 to 20%) for inter-frame compression when the frames share content. For accurate animated estimates, encode a representative short clip and scale up.
Does the tool tell me whether the image will be "good enough"?+
No — perceptual quality is a separate question from bytes. The estimate is for the byte budget; the visual-quality decision is made by previewing the actual encoder output. Use the tool to narrow the format-quality combinations to a small set that fits the byte budget, then encode and inspect to pick the winner on visual quality.

Built by Derek Giordano · Part of Ultimate Design Tools

Privacy Policy · Terms of Service