Skip to main content
Back to Dev generators

Dev

Fake Hash Generator

Seed scripts and fixture files that need a password_hash column should not require a real cryptographic function just to get a placeholder. A fake hash generator produces correctly formatted strings for five algorithms — MD5, SHA-1, SHA-256, SHA-512, and bcrypt — without hashing any real input. Two inputs control the output. Count sets the batch size (1–30). Hash Type determines the format: MD5 outputs 32 lowercase hex characters, SHA-1 outputs 40, SHA-256 outputs 64, SHA-512 outputs 128. bcrypt outputs a $2b$[cost]$[salt][hash] string with a random cost factor between 10 and 14 — the exact format bcrypt.compare() and password_verify() expect. Critical: fake bcrypt hashes will not pass bcrypt.compare() or password_verify() since no real password was hashed. Use them for testing how your code stores and displays hash values, not for scenarios where a password check must succeed.

Read the complete guide — 4 min read

How to use

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

Detailed instructions

  1. Select your desired hash format from the Hash Type dropdown: MD5, SHA-1, SHA-256, or bcrypt.
  2. Set the Number of Hashes count to match how many placeholder values you need for your seed file or test.
  3. Click Generate to produce the hash list instantly in the output panel.
  4. Copy individual hashes by clicking them, or copy the full list to paste into your SQL fixture, JSON mock, or documentation.

Use Cases

  • Seeding password_hash columns in a Postgres fixture file with structurally valid bcrypt strings
  • Populating ETag or checksum fields in mock API responses for Postman or WireMock test suites
  • Generating bulk SHA-256 placeholders for a Cypress end-to-end test that validates 64-char hex input
  • Adding realistic MD5 values to legacy CSV imports during a database migration dry run
  • Writing auth service documentation with concrete bcrypt hash examples instead of placeholder text

Tips

  • For bcrypt columns, generate hashes in the same count as your seed rows so each user record gets a unique placeholder.
  • If your schema enforces a VARCHAR(60) for bcrypt or VARCHAR(64) for SHA-256, verify column length before bulk-inserting — a mismatch will silently truncate or error.
  • Pair SHA-256 fake hashes with a fake UUID generator to create complete mock user records with both an ID and a password hash in one pass.
  • Use MD5 format when seeding legacy systems or testing code that validates 32-character hex — many older PHP and Python apps still write MD5 to the database.
  • When writing API documentation, generate three to five SHA-256 hashes and use them as consistent examples across request and response samples so examples look cohesive.
  • Avoid reusing the same fake hash across multiple rows in a unique-indexed column — generate a fresh batch for each seeding run to prevent constraint violations.

FAQ

how to get a fake SHA-256 hash for unit tests without hashing real data

Select SHA-256 from the Hash Type dropdown, set your count, and click Generate. Each result is a 64-character lowercase hex string — the exact length a real SHA-256 digest produces. Paste them directly into Jest fixtures, Postman mock responses, or SQL seed scripts. No real input is hashed and no crypto library is needed.

will a fake bcrypt hash pass a password_verify or bcrypt.compare check

No. These strings match bcrypt's $2b$[cost]$[salt][hash] structure and satisfy column constraints and length validations, but they are not derived from any password. Any bcrypt.compare() or password_verify() call will return false. Use them for testing queries, migrations, or UI rendering — not for scenarios where login actually needs to succeed.

what are the output lengths for each hash type

MD5 outputs 32 hex characters, SHA-1 outputs 40, SHA-256 outputs 64, and SHA-512 outputs 128. bcrypt outputs a $2b$[cost]$ prefix plus 53 characters of salt and hash, totaling around 60 characters. The generator respects these exact lengths so placeholder values slot into the correct database column size without truncation.

can I use these fake hashes in an ETag or checksum field

Yes. ETags and content-checksum fields typically store hex digest strings without caring about cryptographic derivation — they just need the correct length and character set. SHA-256 fake hashes work well since ETags often use 64-character hex digests, and the placeholder values satisfy format validators without requiring you to hash actual content.

You might also like

Popular tools from other categories that share themes with this one.

Try these next

More free tools from other corners of the catalog, picked by shared themes.