Skip to content

📁 Test Files

Dummy files for upload feature testing, boundary-value tests, and error-handling verification. All files are free and require no signup. MD5 / SHA-256 hashes and curl / wget / PowerShell download commands are included.

By format

By use case

📌 Included with every test file

  • ✅ Byte-precise size guarantee
  • ✅ MD5 / SHA-256 hashes published
  • ✅ curl / wget / PowerShell command examples
  • ✅ Direct links (via CDN / fast download)

Related references

📖 Where people get stuck

Dummy files with known contents, for exercising upload limits and file-handling code. No signup, direct download, each with MD5 / SHA-256 and a ready curl command. Getting one of these through does not prove your handling is safe. What you can check here is how sizes and formats are treated; resistance to disguised extensions, zip bombs and malformed internals needs testing of its own.

Case What happens What to do
A 10 MB file does not arrive as 10 MB multipart/form-data adds a boundary and headers, so the request runs a few hundred bytes larger. Embedded in JSON as base64 it grows by roughly 33%. Use the 9.9 / 10.0 / 10.1 MB threshold files when probing a boundary. If base64 is involved, budget the real limit at about three quarters.
It passes in the browser and fails at the server The limit is not in one place. nginx client_max_body_size, PHP upload_max_filesize and post_max_size, and your own validation each apply independently. The smallest value wins. Keep post_max_size at or above upload_max_filesize, and size it for the total when several files go at once.
Checking the extension lets a disguised file through An executable renamed to .png sails past both an extension check and a Content-Type check, because the sender chooses both of those values. Judge by the leading bytes instead. PNG is 89 50 4E 47, PDF 25 50 44 46, ZIP 50 4B 03 04 — the full table is in the magic bytes reference.
The size fits but the request times out Even inside the size limit, a slow connection takes time to transfer. What cuts the request is not the size cap but a time cap. Raise nginx client_body_timeout and fastcgi_read_timeout together with PHP max_execution_time and max_input_time. Raising only one still leaves the shortest one cutting you off.
Nothing is tested against a broken file Dropped connections and transfer errors mean truncated files and broken headers arrive in production routinely. Plenty of implementations throw at that point and swallow it. Push a deliberately broken file through first, and check it all the way to the message the user actually sees.

Even if every file here goes through, virus scanning, disk exhaustion under concurrent uploads and the limits of your object storage are separate questions. Accepting something up to the limit is not the same as accepting that it should be accepted.