Skip to main content
Back to Dev generators

Dev

Fake File Metadata Generator

Used by developers, writers, and creators worldwide.

The fake file metadata generator creates realistic JSON objects with file names, extensions, MIME types, byte sizes, MD5 and SHA-256 hashes, and ISO 8601 timestamps — no actual files needed. Choose from images, documents, videos, code files, or mixed categories, and generate up to 50 records at once. Developers building upload APIs, storage backends, or CMS integrations hit the same wall: seeding a database or mocking a file listing requires plausible field values, not placeholder strings. A correctly formatted MIME type, a realistic file size, and a hash of the right length all matter when the code consuming that data actually validates those fields.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Select a file category from the dropdown — choose 'Mixed' to span all types or a specific category like 'Images' to scope the output.
  2. Set the count field to the number of metadata records you need, between 1 and 50.
  3. Click Generate to produce the JSON output in the results panel.
  4. Copy the full JSON array or individual objects and paste into your test fixtures, seed scripts, or API mock files.
  5. Re-run the generator as many times as needed — each run produces a fresh set of names, sizes, and hash strings.

Use Cases

  • Seeding a Postgres staging database with 50 mixed-category file records to test pagination queries
  • Populating Cypress fixtures for a drag-and-drop file upload component in a React app
  • Mocking S3 ListObjectsV2 responses with realistic image metadata for filtering and sorting tests
  • Testing MIME type validation middleware in an Express or FastAPI file upload endpoint
  • Generating Postman collection examples for a document management REST API

Tips

  • Generate 'Mixed' category records when testing a generic file manager; they expose MIME type handling bugs that single-category runs miss.
  • Pair image metadata records with a placeholder image service like picsum.photos by mapping the generated file name to a URL — you get plausible end-to-end mock data.
  • When testing deduplication logic, generate two separate batches and manually copy one hash from the first batch into the second to simulate a real duplicate collision.
  • Video records carry large byte sizes by design; use them specifically to test size-limit enforcement and upload progress UI components, not as general-purpose filler.
  • The ISO 8601 timestamps work directly in SQL INSERT statements — wrap them in single quotes and they'll parse correctly in PostgreSQL, MySQL, and SQLite without conversion.
  • For Postman collections, generate 6 to 8 records, paste them into a collection variable as a JSON array, and iterate with a forEach pre-request script to run the same request against multiple mock files.

FAQ

are the md5 and sha-256 hashes in the output real or just random strings

They are randomly generated hex strings of the correct length — 32 characters for MD5, 64 for SHA-256 — and do not correspond to any actual file content. They are safe to use for testing hash-storage logic, deduplication lookups, or display formatting, but not for any cryptographic verification.

can I paste this output directly into a jest or vitest fixture file

Yes. Copy the generated JSON array and paste it into a fixture file or mock factory. Each object already includes the fields most upload handlers expect: name, size, MIME type, and hash. If your code uses the browser File API, you may need to rename 'mimeType' to 'type' to match that property convention.

how realistic are the file sizes — will they catch size-limit bugs

Sizes are generated within ranges typical for each category: roughly 50 KB to 8 MB for images, 10 KB to 50 MB for documents, and up to 2 GB for video records. That spread is realistic enough to trigger pagination edge cases, size-limit validation errors, and UI rendering issues that flat or sequential sizes would miss.