How to Calculate Any File's Size by Hand in 5 Steps

Updated on May 8, 2026

Why Bother Calculating File Size Manually?

You've probably been there: you're about to upload a video to a client portal with a 50 MB limit, or you want to know if a folder of product images will blow past your email attachment cap — and you don't have the actual files in front of you yet. Maybe you're designing a system and need rough estimates before a single byte gets written to disk.

This is where manual file size estimation becomes genuinely useful. It's not a party trick. Engineers do it constantly when speccing storage, photographers do it when quoting archive drives, and anyone managing media workflows benefits from having these numbers in their head. Once you understand the underlying math, you'll stop guessing and start knowing — before the upload even starts.

Let's walk through five concrete steps, covering three of the most common file types: plain text, images, and video.

Step 1: Understand the Base Unit — Bits and Bytes

Everything on a computer is stored as binary digits: ones and zeros, called bits. Eight bits make one byte. That's the foundation everything else builds on.

From there, the units scale up:

  • 1 Kilobyte (KB) = 1,024 bytes (in computing) or 1,000 bytes (in storage marketing — yes, this discrepancy exists and causes confusion)
  • 1 Megabyte (MB) = 1,024 KB
  • 1 Gigabyte (GB) = 1,024 MB

For quick hand estimates, you can round to powers of 1,000 without losing meaningful accuracy. The difference between 1,000 and 1,024 is only about 2.4%, which won't matter when you're estimating whether a file is 30 MB or 300 MB.

Keep this conversion table in the back of your mind as we move through the steps — you'll use it constantly.

Step 2: Calculate Plain Text File Size

Text is the simplest case, and it's a good warm-up. The core insight: in standard ASCII encoding, each character takes exactly 1 byte. That includes letters, numbers, spaces, and punctuation marks.

Here's the formula:

File size (bytes) = number of characters × bytes per character

Let's say you have a document that's roughly 5,000 words. Average English word length is about 5 characters, and each word has a space after it, so call it 6 characters per word on average.

  1. 5,000 words × 6 characters = 30,000 characters
  2. 30,000 characters × 1 byte = 30,000 bytes
  3. 30,000 ÷ 1,000 ≈ 30 KB

If you're using UTF-8 encoding (the modern standard for web content), standard English characters still take 1 byte each. Non-Latin characters — like Hindi, Chinese, or Arabic script — take 2 to 4 bytes per character. A document mixing English and Hindi text might run closer to 2–2.5 bytes per character on average.

Word processors like .docx or .odt add overhead for formatting, fonts, and metadata, which can bloat the file by 5x to 20x compared to raw text. But for estimating raw text content? The character-count method nails it.

Step 3: Estimate Image File Size (Uncompressed vs. Compressed)

Images are where it gets interesting, because you're dealing with two very different numbers: the raw (uncompressed) size and the final stored size after compression.

Start with the raw size. Every image is a grid of pixels, and each pixel stores color data. The number of bits used per pixel is called bit depth.

For a standard RGB image:

  • Red channel: 8 bits
  • Green channel: 8 bits
  • Blue channel: 8 bits
  • Total: 24 bits per pixel (which is 3 bytes per pixel)

Add an alpha (transparency) channel and you're at 32 bits (4 bytes) per pixel.

Raw size formula: width (px) × height (px) × bytes per pixel

Example: a 4000 × 3000 pixel photo at 24-bit color

  1. 4,000 × 3,000 = 12,000,000 pixels
  2. 12,000,000 × 3 bytes = 36,000,000 bytes
  3. 36,000,000 ÷ 1,000,000 = 36 MB uncompressed

Now, nobody stores photos as raw bitmaps. Compression algorithms shrink them significantly. Here are the rough compression ratios you can apply to your raw estimate:

  • JPEG (quality ~80%): divides raw size by roughly 10–20×. Our 36 MB photo becomes about 2–4 MB.
  • PNG (lossless): divides raw size by roughly 2–4× for photographic content, but can achieve 10× for graphics with large flat-color areas.
  • WebP: roughly 25–35% smaller than JPEG at comparable quality — so if JPEG gives you 3 MB, WebP is closer to 2 MB.
  • HEIC/HEIF: similar to WebP, often 40–50% smaller than JPEG.

These are approximations — actual compression varies wildly by image content. A photo of a busy street compresses less efficiently than a blue sky. But for planning purposes, these ratios will get you within striking distance every time.

Step 4: Estimate Video File Size

Video is just a rapid sequence of images (frames) plus audio. The math is a little more involved, but still very manageable by hand.

The key variables are:

  • Resolution: width × height in pixels
  • Frame rate: frames per second (fps) — typically 24, 30, or 60
  • Bit depth: 8-bit (standard), 10-bit (HDR/cinema)
  • Duration: in seconds
  • Compression codec: H.264, H.265, AV1, ProRes, etc.

Start with the theoretical uncompressed data rate:

Raw data rate = width × height × fps × bytes per pixel

Example: 1920 × 1080 video at 30 fps, 8-bit color (3 bytes/pixel)

  1. 1,920 × 1,080 = 2,073,600 pixels per frame
  2. 2,073,600 × 3 bytes = 6,220,800 bytes per frame
  3. 6,220,800 × 30 fps = 186,624,000 bytes per second ≈ 187 MB/s raw

That's enormous — which is exactly why video codecs exist. Here's how to apply codec compression ratios to get a practical estimate:

  • H.264 (web delivery): target bitrate is roughly 5–10 Mbps for 1080p30. At 8 Mbps: 8 Mb/s ÷ 8 = 1 MB/s. A 10-minute video = 600 seconds × 1 MB = ~600 MB.
  • H.265/HEVC: achieves similar quality at about half the H.264 bitrate, so the same 10-minute clip is closer to ~300 MB.
  • 4K H.264: typically 35–45 Mbps. At 40 Mbps (5 MB/s), a 10-minute clip = ~3 GB.
  • Apple ProRes 422 (editing format): around 147 Mbps for 1080p30 — about 18 MB/s, making that same 10-minute clip roughly 11 GB.

The simplest shortcut for compressed video: bitrate (in Mbps) ÷ 8 = MB per second. Multiply by duration in seconds and you're done. Most modern editing and delivery software will tell you the target bitrate, so plug that number in and you'll have a solid estimate in under a minute.

Don't forget audio. A stereo AAC track at 256 kbps adds about 2 MB per minute — usually negligible compared to video, but worth including for longer files.

Step 5: Sanity-Check Your Estimate

Once you've run the numbers, take a step back and ask whether the result passes the common-sense test. Here's a rough mental checklist:

  • A typical smartphone photo (12 MP, JPEG) should land between 3–8 MB. If your estimate says 40 MB, recheck your bit depth or compression ratio.
  • A 1-hour 1080p YouTube video in H.264 is usually 1.5–4 GB. A 10-minute tutorial should be well under a gigabyte.
  • A novel-length plain text file (100,000 words) should be around 600 KB — if your estimate is in the megabytes, double-check your character count math.
  • RAW camera files (Canon CR3, Nikon NEF) are close to the uncompressed size — a 45 MP RAW file is typically 40–60 MB. That passes the sanity check.

If your estimate seems way off from these benchmarks, trace back through the steps. The most common mistakes are: forgetting to divide bits by 8 to get bytes, using the wrong compression ratio for the codec, or confusing megabits with megabytes (especially with video bitrates, which are always quoted in bits per second, not bytes).

Putting It All Together

You now have a repeatable, five-step method for estimating file sizes from scratch — no tools required, no guesswork. The underlying pattern is always the same: figure out your raw data volume based on content dimensions, then apply a realistic compression factor for the format you're working with.

These estimates won't be exact — real-world files vary based on content complexity, encoder settings, and metadata overhead. But they'll be close enough to make decisions: whether a batch of assets will fit on a drive, whether a video needs re-encoding before upload, or whether a text export will sail under an API payload limit.

The more you practice this kind of back-of-envelope thinking, the faster your gut calibration becomes. After a while, you'll look at a project spec and know within seconds whether the storage budget makes sense — before a single file exists.