A 50 MB ZIP test file

About this file

A 50 MB test file in ZIP format, sized to exactly 52,428,990 bytes. Free to download with no signup, for verifying upload limits and file-handling behaviour.

The MD5, SHA-1 and SHA-256 values listed above are the real digests of this file. Recomputing them after download confirms the transfer was not corrupted, and they double as known-good expected values when testing a hashing library.

What this size means in practice

50 MB is the point where GitHub starts warning you on push (it hard-rejects above 100 MB). In practice it is the decision line for whether a binary belongs in Git directly or should move to Git LFS.

At this scale, an implementation that buffers the whole request in memory burns 50 MB or more per worker process — ten concurrent uploads means 500 MB. It is a good size for verifying that streaming or spill-to-temp-file actually works.

Getting a feel for this size

On a 10 Mbps link the transfer takes roughly 41.9 seconds, and about 4.2 seconds at 100 Mbps. Base64-encoded it grows to roughly 68,267 KB.

ZIP compression ratios differ by orders of magnitude depending on the contents: text-heavy archives expand three to five times, while already-compressed images or video barely change. Use this 50 MB archive to decide whether your disk-space checks need to account for the uncompressed size.

What to check for this format

ZIP starts with PK\x03\x04, but the listing of its contents — the central directory — lives at the end of the file. Reading only the beginning tells you nothing about the contents, and losing the tail makes extraction impossible.

• Whether you cap the total uncompressed size — a zip bomb abuses the compression ratio so that a few KB expand to gigabytes
• Whether entry names containing ../ are rejected — this is the Zip Slip directory-traversal attack
• Whether you can extract while streaming, or must first write the whole archive to disk