What determines the size of an image
An uncompressed image is a rectangle of numbers, and its size is completely determined by three things: how many pixels there are, how many samples are stored per pixel, and how many bits each sample uses. Multiply them and divide by eight. Everything else — file format, metadata, colour profile, thumbnail — is small by comparison and predictable.
The number people usually quote, megapixels, only captures the first of the three. A 24-megapixel frame is 72 MB as 8-bit RGB, 144 MB as 16-bit RGB, and 36 MB as a 12-bit single-channel raw. Same sensor, same scene, four-fold spread. That is why “how much does a 24 MP photo take” has no single answer until you say what is being stored.
Channels are where most mistakes happen. A camera raw file records one sample per photosite behind a colour filter array, not three: the red, green and blue values at each location are interpolated later by the demosaicing step. So a 24 MP 14-bit raw is 24,000,000 × 14 ÷ 8 = 42 MB before its own lossless compression, not the 126 MB you would get by treating it as three channels. Meanwhile a screenshot with transparency is four channels, and a print-ready CMYK file is four channels of a different kind.
Compression is the one term the arithmetic cannot give you. A JPEG or WebP encoder discards information the eye is unlikely to miss, and how much it discards depends on the quality setting and on what is in the frame. A photograph of a clear sky compresses far harder than the same camera pointed at a hedge, at identical settings. The ratio input here is your estimate, and the honest way to get it is to encode a representative sample and divide.
Working the formula, and the two conventions that trip people
Start with pixels: w × h. Then bits per pixel: channels × bits per channel. An 8-bit RGB pixel is 24 bpp, an 8-bit RGBA pixel is 32 bpp, a 16-bit RGB pixel is 48 bpp, and a 1-bit bilevel scan is 1 bpp. Multiply and divide by eight for bytes.
Convention one: which megabyte. Storage vendors, and this calculator, use SI prefixes — a megabyte is 106 bytes and a gigabyte is 109. Operating systems have historically reported the binary quantities, 220 and 230, while still calling them MB and GB. IEC 80000-13 names those mebibyte (MiB) and gibibyte (GiB) precisely to end the ambiguity. The gap compounds: 7% at gigabytes, 10% at terabytes. A 64 GB card really does hold 64,000,000,000 bytes; a system that reports it as 59.6 GB is showing you gibibytes. The TB to TiB storage calculator converts between the two.
Convention two: row padding. Formats that store rows independently usually pad each one to a whole number of bytes, or to a 4-byte boundary in the case of Windows BMP. At 24 bpp and an even width this changes nothing; at 1 bpp, 10 bpp or 12 bpp it adds up. The calculator warns when your bits per pixel is not a multiple of eight, and the real file will then be a little larger than the ideal figure.
The mipmap third. A mipmap chain stores the texture at half resolution, then a quarter, and so on. Each level has one quarter the pixels of the one above, so the total is 1 + 1/4 + 1/16 + 1/64 + …, a geometric series with ratio 1/4 that sums to 4/3. A full chain therefore costs exactly one third more than the base image — a useful constant to have memorised, and one that does not depend on the texture's size.
Worked example: a 24 MP shoot onto a 64 GB card
You are shooting a 6000 × 4000 sensor and exporting 8-bit RGB JPEGs at a quality setting that historically gives you about 8:1 on this kind of subject. The card is 64 GB and you expect around 500 frames.
- Pixels. 6,000 × 4,000 = 24,000,000, which is 24 MP.
- Bits per pixel. 3 channels × 8 bits = 24 bpp, so 3 bytes per pixel.
- Uncompressed bytes. 24,000,000 × 24 ÷ 8 = 72,000,000 bytes, which is 72 MB.
- Compressed estimate. 72,000,000 ÷ 8 = 9,000,000 bytes, or 9 MB per frame.
- Frames on the card. 64,000,000,000 ÷ 9,000,000 = 7,111.1, so 7,111 whole images.
- Storage for the shoot. 500 × 9,000,000 = 4,500,000,000 bytes, which is 4.5 GB.
Now shoot raw instead. A 14-bit single-channel raw from the same sensor is 24,000,000 × 14 ÷ 8 = 42,000,000 bytes, and lossless raw compression typically lands somewhere near 1.5:1, giving about 28 MB a frame — roughly three times the JPEG. The card now holds about 64,000,000,000 ÷ 28,000,000 = 2,285 frames, and the 500-frame shoot needs 14 GB. Shooting raw and JPEG together costs the sum of the two, 37 MB a frame, and cuts the card to about 1,729 frames.
The same 6000 × 4000 image as a 16-bit RGB working file in an editor is 24,000,000 × 48 ÷ 8 = 144,000,000 bytes, and every additional layer at full size adds another 144 MB before the editor's own compression. That is why layered masters outgrow their originals so quickly.
How to use the numbers
For a card, plan on fewer frames than the calculation gives. The capacity printed on the card is before formatting, the filesystem consumes some of it, sidecar and thumbnail files add a little, and file sizes vary frame to frame — a burst of detailed subjects will be larger than your average. Treating the calculated count as a ceiling and carrying a second card is the practical response.
For a web page, the uncompressed figure is the one that matters for memory even though the compressed figure is what crosses the network. A browser decodes a 4000 × 3000 JPEG into 48 MB of RGBA pixels regardless of the fact that the file was 2 MB, and it does that for every image on the page. Serving a 400 × 300 version instead reduces the decoded footprint by a factor of 100, which is why responsive image sizes matter more for memory-constrained devices than the download size suggests.
For a GPU, the uncompressed figure is the memory cost unless you use a block-compressed format. BC1/DXT1 stores 4 bits per pixel and BC3/DXT5 stores 8, against 32 for uncompressed RGBA — a fixed 8× or 4× saving that the hardware decodes on the fly, unlike a JPEG which must be fully decoded into a bitmap first. Add the mipmap third on top of whichever you choose. A texture budget is quickly consumed: 200 textures at 1024 × 1024 RGBA with mipmaps is 200 × 5.59 MB = 1.12 GB.
For archives, multiply by every copy. A working master, an offsite backup and a delivery export are three copies, and a versioned system may hold many more. The total-storage output here covers one copy of one set; multiply by your retention policy before sizing a disk, and check the result against the backup retention storage calculator.
If you need to embed an image directly in HTML or JSON rather than linking to it, remember that base64 adds a third to whatever the compressed size is. The base64 encoded size calculator gives the exact figure including padding.
Bytes per pixel and megabytes per megapixel
| Pixel format | Bits per pixel | Bytes per pixel | MB per megapixel | 24 MP frame |
|---|---|---|---|---|
| 1-bit bilevel | 1 | 0.125 | 0.125 | 3 MB |
| 8-bit grayscale | 8 | 1 | 1 | 24 MB |
| 12-bit Bayer raw | 12 | 1.5 | 1.5 | 36 MB |
| 14-bit Bayer raw | 14 | 1.75 | 1.75 | 42 MB |
| 8-bit RGB | 24 | 3 | 3 | 72 MB |
| 10-bit RGB | 30 | 3.75 | 3.75 | 90 MB |
| 8-bit RGBA | 32 | 4 | 4 | 96 MB |
| 12-bit RGB | 36 | 4.5 | 4.5 | 108 MB |
| 16-bit RGB | 48 | 6 | 6 | 144 MB |
| 16-bit RGBA | 64 | 8 | 8 | 192 MB |
| 32-bit float RGBA (HDR) | 128 | 16 | 16 | 384 MB |
Megabytes here are 10⁶ bytes, so MB per megapixel and bytes per pixel are numerically identical — a convenient coincidence of the decimal convention that does not hold if you work in mebibytes.
Compression ratio is an assumption, not a calculation
No formula predicts what a lossy encoder will produce, because the output size depends on the content. Detail, noise, texture and grain all resist compression; flat areas and smooth gradients do not. Two frames from the same camera at the same quality setting can differ by a factor of three, and raising ISO — which adds noise — reliably increases file size at a fixed quality setting.
The only trustworthy ratio is one you measure. Encode twenty representative frames at your chosen settings, add up the file sizes, and divide the total bitmap size by the total file size. Use that number here. If you are sizing a card for a job you have not shot yet, take the ratio from the most detailed subject you expect rather than the average, and keep the headroom.
Lossless formats behave differently again. PNG on a photograph often achieves little better than 1.5:1, while PNG on a screenshot with large flat regions can exceed 10:1 — the opposite ordering to what people expect from a lossy encoder.
What this calculation leaves out
- Metadata. EXIF, IPTC and XMP blocks are typically a few kilobytes, and an embedded ICC profile adds a few more. Negligible for a photograph, significant for a large set of tiny icons.
- Embedded previews. Raw files usually carry a full-size JPEG preview so that the camera and file browser can display them, which can add several megabytes per frame.
- Filesystem overhead. Files occupy whole allocation units. With a 32 KB cluster size, a set of small thumbnails wastes an average of 16 KB each.
- Row padding. Formats that align each row to a byte or a 4-byte boundary add a little, and the effect is largest at low bit depths and awkward widths.
- Chroma subsampling. JPEG at 4:2:0 stores colour at quarter resolution before the transform stage, which is part of why the achieved ratio is high. It is folded into your measured ratio, not modelled separately.
- Alpha you did not ask for. Many editors save RGBA even when the image is fully opaque, adding a third to an 8-bit file.
- Layers, masks and history. A layered master is a multiple of the flattened size, and a smart-object copy of the original can double it again.
Key terms
- Bits per pixel (bpp)
- Channels multiplied by bits per channel. The single number that, with the pixel count, determines uncompressed size.
- Bayer raw
- Sensor data stored as one sample per photosite behind a colour filter array. Full colour is interpolated later, so a raw file is roughly one third the size of the RGB image it becomes.
- Mipmap
- A precomputed chain of successively half-sized copies of a texture, used to avoid aliasing when the texture is drawn small. A complete chain adds exactly one third to the memory footprint.
- Block compression
- GPU texture formats such as BC1 and BC3 that store fixed-size compressed blocks the hardware decodes during sampling, giving a constant 4× or 8× saving with no decode step.
- Mebibyte (MiB)
- 2²⁰ = 1,048,576 bytes, defined in IEC 80000-13 to distinguish the binary quantity from the SI megabyte of 10⁶ bytes. The two differ by about 4.9%.
Where image size sits among the other media calculations
Still images and video are the same arithmetic with time added. A video frame costs exactly what this calculator says, and an uncompressed stream costs that per frame times the frame rate — which is why uncompressed video is essentially never stored and why codecs work across frames rather than within one. Size a delivery stream with the video bitrate and file size calculator, which starts from a bitrate rather than from a per-frame bitmap.
Two neighbouring questions come up constantly alongside this one. How many pixels you need in the first place depends on how large the image will be reproduced and how close the viewer is, which is a pixel-density question — see the screen PPI and pixel density calculator. And whether your target dimensions preserve the source framing is an aspect ratio question, which decides how much of the frame a resize crops away.
Finally, if you are evaluating a codec or a storage system rather than a single file, the useful figure is the ratio itself rather than either size. The data compression ratio calculator converts between ratios, percentage space saved and bits per pixel, which are three ways of stating the same measurement and are routinely confused in specifications.