A 1 MB ZIP test file

About this file

A 1 MB test file in ZIP format, sized to exactly 1,048,764 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

1 MB is exactly the nginx client_max_body_size default (1m). Behind a reverse proxy where nobody set that directive, anything larger never reaches your application — nginx answers 413 Request Entity Too Large itself.

That makes it the ideal size for reproducing the classic incident where the app limit was raised to 10 MB yet uploads still fail at 1 MB. If the 413 never appears in your application log, the cause is almost always the proxy layer in front of it.

Getting a feel for this size

On a 10 Mbps link the transfer takes roughly 839 ms, and about 84 ms at 100 Mbps. Base64-encoded it grows to roughly 1,366 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 1 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