What the result contains
What This Tool Provides
Generate RFC 9562 identifiers in the browser: version 4 for 122 bits of pure randomness, or version 7 when you want identifiers that sort by the moment they were created. Choose how many, whether to keep hyphens, upper or lower case, and braces. Paste an identifier you already have and the tool reads its version back out.
- Version 4 or version 7 identifiers from the platform CSPRNG
- Up to 500 at a time, one per line for pasting into a fixture or seed file
- Case, hyphen, and brace formatting applied to every value
- A version and variant reading for any UUID you paste in
How to Use This Tool
- Pick a versionVersion 4 is random. Version 7 puts a millisecond timestamp in front, so values sort chronologically.
- Set the count and formatChoose how many you need, then hyphens, case, and braces to match wherever they are going.
- Copy or inspectCopy all of them at once, or paste an existing identifier into the inspector to see which version it is.
How It Works
A UUID is 128 bits displayed as 32 hexadecimal characters in an 8-4-4-4-12 layout. Six of those bits are not free: four encode the version and two encode the variant, which is why the fifteenth character of a v4 is always 4 and the twentieth is always 8, 9, a, or b. Version 4 fills the remaining 122 bits from crypto.getRandomValues, the platform’s cryptographically secure generator, never Math.random. Version 7 replaces the leading 48 bits with the current time in milliseconds since 1970, then fills the rest randomly, so lexical order matches creation order.
Worked Examples
A version 4 identifier
- Input
Version 4, one value- Output
f47ac10b-58cc-4372-a567-0e02b2c3d479
The 4 at position 15 and the a at position 20 are the version and variant fields; everything else is random.
Version 7 sorts by time
- Input
Two values generated five months apart- Output
0194a1b2-c3d4-7000-8000-000000000000 019a5f60-1234-7000-8000-000000000000
Sorting these as plain strings puts them in creation order, which is what keeps a database index from fragmenting.
Reading a version back out
- Input
c232ab00-9414-11ec-b3c8-9f6bdeced846- Output
Version 1 · RFC 9562 variant
Version 1 embeds a timestamp and a MAC address, so an identifier like this can reveal the machine that produced it.
Choosing Between Version 4 and Version 7
Version 4 is the safe default: 122 random bits, nothing inferable from the value, and no coordination needed between the machines producing them. Its weakness is physical, not cryptographic — random keys scatter inserts across a B-tree index, so a busy table pays in page splits and cache misses.
Version 7 fixes exactly that by putting a 48-bit millisecond timestamp first. New rows land next to each other, and the identifier still carries 74 random bits, which is far more than enough to avoid collisions within a millisecond. The trade is that a v7 leaks its creation time to anyone holding it. For a primary key that is usually fine; for a password-reset token or a public share link it may not be.
What Each Version Encodes
| Version | Built from | Worth knowing |
|---|---|---|
| 1 | Timestamp plus MAC address | Can identify the machine that generated it |
| 3 | MD5 of a namespace and name | Deterministic: same input, same UUID |
| 4 | 122 random bits | No embedded time or machine data |
| 5 | SHA-1 of a namespace and name | Deterministic, preferred over version 3 |
| 7 | 48-bit timestamp plus random bits | Sorts by creation time; reveals creation time |
Collisions, Honestly
The usual claim is that version 4 collisions are impossible. They are not impossible, they are negligible: with 122 random bits you would need to generate on the order of a billion identifiers a second for decades before a 50% chance of a single collision arises. What actually causes duplicate UUIDs in production is never the maths — it is a weak generator such as Math.random, a copied fixture file, a restored database snapshot, or an identifier truncated to fit a column. This tool uses the platform CSPRNG, which removes the first cause and none of the others.
Identifiers in the Rest of a Workflow
An identifier is rarely the end of a task. Batches generated here usually go straight into a seed or fixture file, and once they are wrapped in a payload it is worth formatting that JSON to confirm the structure is what the API expects. When a UUID becomes part of a URL — a share link, a callback — the braces and uppercase forms need percent-encoding for the query string before they are safe to paste.
For secrets rather than identifiers, a UUID is the wrong tool: a generated password is what you want when the value must resist guessing, because a v7 UUID broadcasts when it was made. To fingerprint a file or a key instead of naming a record, a SHA-256 digest is the right primitive. And when a <code>sub</code> or <code>jti</code> claim inside a token turns out to be a UUID, decoding the token shows you which record it points at, while Base64 decoding is what you need when the identifier arrives packed into a binary blob rather than printed as hex.
Important Edge Cases
- crypto.getRandomValues needs a secure context, so a page served over plain http on a remote host cannot generate values here.
- Two version 7 identifiers created in the same millisecond are ordered by their random bits, not by their true sequence.
- Stripping hyphens makes a valid 32-character form, but some databases and APIs accept only the hyphenated layout.
- The nil UUID of all zeroes and the max UUID of all ones are valid values with special meanings, not errors.
- A version 1 identifier pasted into the inspector may reveal the MAC address of the machine that made it.
Limitations
- Only versions 4 and 7 are generated. Versions 3 and 5 are name-based and need a namespace and a hashing step this tool does not offer.
- Version 7 depends on your device clock; a clock set wrongly produces identifiers that sort wrongly.
- Uniqueness is a statistical property, not a guarantee, and nothing here can detect a collision with a value generated elsewhere.
- A maximum of 500 identifiers is generated at once to keep the page responsive.
- The tool does not check whether an identifier is already in use anywhere.
Input handling
Private Browser Processing
Identifiers are generated on your device by the browser’s own random number generator. Nothing is requested from a server, and generated values are not stored or transmitted.
Google Analytics records page visits and whether a tool finished or failed, but these tool implementations do not send field values, generated passwords, QR payloads, uploaded QR images, or camera frames to analytics or a Tiny Tiny Tools processing endpoint.
See the Privacy Policy for site-wide details.
Questions About This Tool
Are these UUIDs safe to use as database keys?
Yes. Version 4 is the common default, and version 7 is usually the better choice for a primary key because time-ordered values keep the index compact. Both come from the platform cryptographic generator here.
Can a UUID be used as a password or API key?
It is a poor fit. A version 7 UUID reveals when it was created, and even a version 4 is a fixed format that tells an attacker exactly what shape to expect. Generate a password when the value has to resist guessing.
Will two people using this page ever get the same UUID?
Not in any practical sense. Version 4 draws 122 random bits from a cryptographic generator; the realistic causes of duplicate identifiers are copied fixtures and restored snapshots, not the randomness.
Why does my UUID have a 7 where others have a 4?
That character is the version field. A 4 means the value is random; a 7 means the first 48 bits are a millisecond timestamp. Paste any identifier into the inspector to read its version.
Is version 7 a real standard?
Yes. RFC 9562 published in May 2024 replaced RFC 4122 and defines versions 6, 7, and 8 alongside the older ones.