An image file size calculator answers the question before the file exists. Given a resolution, a colour model, a bit depth and a format, how many bytes will this image occupy? That is the question you need answered when buying memory cards, planning a shoot, budgeting storage for an archive or deciding what resolution a website can afford to serve.
Arb Digital publishes this in its free tools library, and the distinction against the neighbouring tools matters. The image compressor and the image resizer process a file you upload and give you back a smaller one. This page processes nothing. It takes numbers you type and returns arithmetic, which means it works for photographs that have not been taken yet and for exports that have not been run. The video file size calculator does the same job for moving footage.
What This Image File Size Calculator Does
It computes the uncompressed size exactly, then applies a compression ratio to estimate the delivered file. The uncompressed figure is not an approximation: pixels multiplied by channels multiplied by bit depth, divided by eight, is precisely how many bytes the raw pixel data occupies. Everything uncertain lives in the second step.
The format selector loads typical ratios for photographic content, and every one of them is editable, because a compression ratio is a property of the image rather than the codec. The results grid shows megapixels, the effective bits per pixel after compression, and the total across however many images you specify — which is the figure that actually determines whether a card or a drive is large enough.
The units selector exists because storage is sold in decimal megabytes of a million bytes while several operating systems report binary mebibytes of 1,048,576 bytes. That is a 4.9% difference at the megabyte scale and 7.4% at the gigabyte scale, and it explains a great deal of confusion about capacities that seem to shrink on arrival.
How to Use It
- Enter the pixel dimensions, not the print size. File size depends on pixel count alone. A 300 DPI setting changes nothing about the bytes; it only changes how large the image prints, which is what the DPI and PPI calculator handles.
- Set the channel count to match the colour model. Greyscale is one channel, RGB is three, and RGBA or CMYK is four. Adding an alpha channel to an RGB image increases the raw size by a third.
- Choose the bit depth your capture or export actually uses. Moving from 8-bit to 16-bit doubles the uncompressed data exactly, and the extra levels are only useful if heavy editing follows.
- Pick a format, then override the ratio if you have measured your own. The presets are reasonable starting points for photographs. If you have exported a few representative files, dividing the uncompressed figure by their actual size gives a ratio far better than any default.
- Read the batch total before buying storage. Add headroom — cards should not be filled to capacity, and archives grow.
The Formula / How It's Calculated
The uncompressed size is a single multiplication:
Bytes = width × height × channels × bit depth ÷ 8
The estimated compressed size divides that by the ratio: compressed bytes = uncompressed bytes ÷ ratio. Effective bits per pixel is compressed bytes × 8 ÷ (width × height), and the batch total is simply the compressed size multiplied by the image count.
Worked example, matching the values the page loads with. A 6000 × 4000 image is 24,000,000 pixels, or 24.0 megapixels. In RGB at 8 bits per channel that is 24 bits — three bytes — per pixel, so the uncompressed data is 72,000,000 bytes: 72.00 MB decimal, or 68.66 MiB binary. At a JPEG quality 80 ratio of about 10:1 the estimated file is 7,200,000 bytes, or 7.20 MB, which works out at 2.4 effective bits per pixel. Five hundred such images total 3,600,000,000 bytes — 3.60 GB, or 3.35 GiB as a file manager would report it. The Library of Congress format description for the JPEG image encoding family documents the underlying encoding.
Why the Compression Ratio Is a Property of the Picture
This is the part that explains why two files from the same camera at the same settings can differ threefold in size, and why any single-number estimate is inherently a range.
Lossy compression works by discarding detail the eye is poor at noticing, and how much there is to discard depends entirely on the content. A studio portrait against a seamless backdrop is mostly smooth gradients: the encoder finds long runs of similar values and represents them with very few bits. The same camera pointed at a hedge produces high-frequency detail in every block, and there is nothing to throw away without visible damage. Ratios of 20:1 and 4:1 from identical settings are both routine.
Noise makes this worse in a way that surprises people. Sensor noise is high-frequency random data, which is the least compressible thing an encoder can be handed. A photograph shot at a high ISO can produce a file two or three times larger than the same scene shot at base ISO, because the encoder is faithfully preserving grain. Noise reduction applied before export therefore reduces file size as a side effect.
Lossless formats behave differently but follow the same principle. PNG uses prediction filters and DEFLATE, which excel on flat colour and hard edges — screenshots, logos, diagrams — and achieve very little on photographs, often no better than 1.4:1. That is why a screenshot saved as PNG is small and the same-sized photograph saved as PNG is enormous, and why choosing PNG for photographic content is one of the most common causes of a slow-loading page. The Portable Network Graphics (PNG) Specification (Third Edition) at W3C sets out the filtering and compression model in detail.
Bit Depth Costs More Than It Usually Returns
Bit depth multiplies the raw data linearly: 16-bit is exactly twice 8-bit, and 12-bit is 1.5 times. What it buys is levels per channel — 256 at 8 bits, 65,536 at 16 — and those extra levels matter in exactly one situation.
That situation is editing. Pushing exposure, recovering shadows or applying strong curves stretches the tonal data, and at 8 bits the gaps between remaining levels can become visible as banding in smooth areas like skies. At higher depths the stretch has material to work with. The benefit is real during processing and almost entirely absent in the delivered file, because a display showing 8 bits per channel cannot present more.
The practical implication is to keep depth where the editing happens and drop it where the delivery happens. A 16-bit TIFF working file at 6000 × 4000 in RGB occupies 144,000,000 bytes uncompressed. The same image exported as an 8-bit JPEG for the web is under eight megabytes. Storing the delivery file at the working depth costs eighteen times the space for a difference nobody will see.
Alpha channels deserve the same scrutiny. A fourth channel adds a third to the raw size, and it is only doing work if part of the image is genuinely transparent. Exporting logos and product cutouts with alpha is correct; exporting a full-bleed photograph with an entirely opaque alpha channel is paying a third more for nothing.
Sizing Storage, Cards and Web Delivery
Three planning problems use this calculator in different directions.
Memory cards. Divide the card's capacity by the estimated per-image size to get a shot count, then reduce it. Cards perform badly when nearly full, RAW files vary more than JPEGs, and burst shooting on a partly filled card is where write speed problems appear. Card capacities are quoted in decimal gigabytes, so switch the units selector to decimal when doing this arithmetic or you will overestimate by around 7%.
Archives. Multiply through the batch total, then account for the versions nobody plans for: the original capture, the edited master, and the exports. An archive is commonly two to three times the size of the raw capture volume. The data storage converter handles the unit arithmetic when the numbers reach terabytes.
Web delivery. Here the target is a byte budget rather than a capacity. Work backwards: decide what a page can afford, divide by the number of images, and use this calculator to find the resolution and format that fit. Modern formats change the answer substantially — the same photograph that needs 7.2 MB as a quality-80 JPEG at full resolution typically lands under half that in WebP or AVIF at comparable visual quality, and serving it at the dimensions it will actually be displayed at usually matters more than either. The WebP converter and image compressor handle the conversion once the target is decided.
Arb Digital builds sites where large photography loads fast — correct dimensions, modern formats, and a layout that stays stable while images arrive.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Assuming DPI affects file size — it does not. Only pixel dimensions determine bytes; DPI is metadata describing intended print size.
- Using one compression ratio for a whole shoot — detailed and noisy frames can be several times larger than clean, smooth ones from the same camera and settings.
- Saving photographs as PNG — lossless compression achieves very little on photographic content, so the file can be five to ten times a comparable JPEG for no visible gain.
- Mixing decimal and binary units — a card sold as 64 GB reports as roughly 59.6 GiB, and comparing the two without converting makes capacity appear to vanish.
- Delivering at working bit depth — 16-bit is for editing headroom, and shipping it to a display that shows 8 bits doubles the bytes for no perceptible difference.
Related Free Tools From Arb Digital
Compress or convert an actual file with the image compressor and the WebP converter, resize one with the image resizer, and plan dimensions with the aspect ratio calculator or the DPI and PPI calculator. The video file size calculator covers moving footage, the data storage converter handles unit conversion, and the depth of field calculator covers the optical side of the same shoot. Everything else is in the free online tools hub.
Frequently Asked Questions
No. It performs arithmetic on numbers you type, so nothing leaves your browser and no file is needed. That is what makes it usable before a photograph exists — for planning a shoot, sizing a memory card or budgeting an archive.
No. File size depends only on pixel dimensions, channels and bit depth. DPI is a metadata tag describing how large the image should print, and changing it from 72 to 300 alters the printed dimensions while leaving every byte of pixel data untouched.
Because compression ratio depends on image content. Smooth areas compress far better than fine detail, and sensor noise is close to incompressible. Ratios from 4:1 to 20:1 all occur at the same quality setting, which is why the ratio field is editable.
Exactly double the uncompressed data. The extra levels give editing headroom that prevents banding when tones are stretched, but they make no visible difference in a delivered file viewed on a normal display, so the usual approach is to edit deep and export at 8 bits.
Storage is sold in decimal units where a gigabyte is 1,000,000,000 bytes, while many operating systems report binary gibibytes of 1,073,741,824 bytes. The difference is about 7% at that scale. The units selector on this page switches between the two conventions.
JPEG, WebP or AVIF for photographic content. PNG is lossless and excels on flat colour, hard edges and screenshots, but achieves very little on photographs, so a PNG photograph is often many times larger than a visually equivalent JPEG.
Start from the sensor's bit depth — commonly 12 or 14 bits on a single channel before demosaicing rather than three channels — and apply a modest lossless ratio of roughly 1.5:1 to 2:1. Compressed RAW formats vary between manufacturers, so measuring a few of your own files gives a better ratio than any default.
Yes. A fourth channel increases the uncompressed data by a third, and it only earns that cost if part of the image is genuinely transparent. Exporting an opaque photograph with an unused alpha channel is a common and avoidable waste.
