UUID & Hash Generator
Generate v4 UUIDs, hash text with MD5/SHA-1/SHA-256/SHA-512, and make passwords.
UUID v4: what those 122 random bits buy you
A UUID is a 128-bit identifier, written as 32 hexadecimal digits in the familiar 8-4-4-4-12 grouping. Version 4 — the kind nearly everyone means by "UUID" — uses 6 bits for version and variant metadata and fills the remaining 122 bits from a cryptographically secure random source.
550e8400-e29b-41d4-a716-446655440000
↑ ↑
version 4 variant bitsWhy 122 bits rather than 64? Because identifiers are generated independently by many machines that never coordinate, and collisions are not merely untidy — they are correctness bugs that are extremely hard to reproduce. The birthday bound tells you the risk. With 122 random bits you would need to generate roughly 2.7 × 1018 identifiers — 2.7 quintillion — before reaching a 1% probability of a single collision. At a sustained rate of a billion UUIDs per second, that is about 85 years.
This tool uses crypto.randomUUID() where available and
crypto.getRandomValues() otherwise. Both are cryptographically secure.
That distinction matters: Math.random() is not cryptographically
secure and must never be used to generate identifiers, tokens or passwords.
Random UUIDs are not sortable — and that has a cost
Because v4 UUIDs are random, inserting them as a primary key scatters writes across the entire index. In a B-tree this causes page splits, fragmented indexes, and measurably worse write performance and cache locality at scale — a well-documented issue on MySQL and PostgreSQL with large tables.
If you need time-ordered identifiers, use UUID v7, which embeds a timestamp in the leading bits so values sort chronologically while retaining global uniqueness. It is formalised in RFC 9562 and increasingly supported by database extensions and libraries. The practical guidance:
- Exposed in an API or URL? Use a UUID (v4 or v7) rather than an auto-increment integer, which leaks your row count and lets anyone enumerate your records.
- High-volume insert-heavy table? Prefer UUID v7, or keep an internal bigint key and expose a UUID separately.
- Distributed generation with no coordination? UUID is the right answer. Snowflake-style IDs need a node-ID assignment scheme.
Hashing: which algorithm to use
A cryptographic hash is deterministic (same input, same output), fixed-length, and designed so that finding two inputs with the same output is computationally infeasible. But the algorithms are not interchangeable — several are broken:
- MD5 — broken. Practical collisions have been constructible since the mid-2000s and are now cheap. Use it only for non-adversarial checksums, such as detecting whether a file changed during a copy. Never for passwords, signatures or integrity against an attacker.
- SHA-1 — broken. A practical collision (SHAttered) was demonstrated in 2017 and chosen-prefix collisions have followed. Deprecated by every major browser and CA. Legacy systems only.
- SHA-256 — the default choice. Part of SHA-2, no known practical weaknesses. Use it for file integrity, content addressing, and as the primitive inside HMAC.
- SHA-512 — SHA-2 with a larger output. Often faster than SHA-256 on 64-bit hardware. Use when you want a larger security margin or longer digests.
Hashing a password is not the same as hashing a file
This distinction causes a great many breaches. A fast hash such as SHA-256 is exactly wrong for passwords, because an attacker with your database can test billions of candidates per second on a GPU. Password storage requires a deliberately slow, salted, memory-hard function:
- Argon2id — the current recommendation, winner of the Password Hashing Competition. Use it if your platform supports it.
- bcrypt — still acceptable and extremely widely deployed. Note it silently truncates input past 72 bytes.
- scrypt — good, memory-hard, less common than the two above.
Never use SHA-256 alone for passwords, never use MD5, and never roll your own scheme. Use a maintained library that handles salt generation and parameter tuning for you.
What makes a strong password here
The generator draws from the browser's CSPRNG and shuffles the result, so the output
is unbiased. It guarantees at least one character from each selected class. Entropy is
computed as length × log2(alphabet size), which is the honest measure of
strength — length matters far more than symbol substitution. A 20-character password
from a 70-character alphabet gives roughly 122 bits of entropy, which is well beyond
anything brute-forceable.
Two practical notes: passwords generated this way are meant for a password manager, not for memorising; and if a site rejects your generated password, that is a security signal about the site — arbitrary maximum-length limits and character restrictions usually mean passwords are being stored insecurely.
Frequently asked questions
Yes. They use the browser's cryptographically secure random number generator (crypto.randomUUID / crypto.getRandomValues), not Math.random(). Values are generated on your device and never transmitted.
Theoretically yes, practically never. With 122 random bits you would need to generate about 2.7 quintillion UUIDs for a 1% chance of a single collision.
Not for anything security-related — practical collisions are cheap to produce. It remains acceptable as a non-adversarial checksum for detecting accidental corruption. Use SHA-256 for integrity against an attacker.
No. SHA-256 is fast, which is exactly what you do not want for passwords: it lets an attacker test billions of guesses per second. Use a slow, salted, memory-hard function such as Argon2id or bcrypt.
A newer UUID version (RFC 9562) that embeds a timestamp in the leading bits, so values sort chronologically. Use it for high-volume database primary keys, where random v4 UUIDs cause index fragmentation.
You can internally, but exposing them in URLs leaks your record count and lets anyone enumerate your data. A common pattern is an internal integer key plus an exposed UUID for external references.