Quick answer
A UUID is a 128-bit identifier written as 36 characters in 8-4-4-4-12 groups, such as 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. A v4 UUID holds 122 random bits; a v7 UUID (RFC 9562, 2024) starts with a millisecond timestamp, so values sort by creation time and make good database primary keys.
What is a UUID?
Generate one or up to 1,000 UUIDs at a time, as v4 (random, using the browser's crypto.randomUUID) or v7 (time-ordered, still in order when many are created within the same millisecond). Switch to uppercase, drop the hyphens or wrap them in braces Microsoft-GUID style, then copy them or download a .txt file. The inspector tells you the version and variant of any UUID and, for v1, v6 and v7, when it was created.

How to generate and inspect UUIDs
- 1
Choose a version: “v4 · random” for ordinary unique IDs, or “v7 · time-ordered” when IDs should sort by creation time.
- 2
Enter how many you need (1–1,000) and click “Generate again”; switching version also regenerates the list.
- 3
Toggle UPPERCASE, hyphens or braces to suit the target system; the list reformats instantly without creating new IDs.
- 4
Click “Copy all” or “Download .txt”. To read an existing UUID, paste it into “Inspect / decode a UUID”.
UUID versions
| Version | Built from | Sorts by time | Use it when |
|---|---|---|---|
| v1 | 100 ns timestamp + MAC address | No (byte order is shuffled) | Legacy systems; exposes the machine's MAC address |
| v3 / v5 | MD5 / SHA-1 hash of a name + namespace | No | The same input must always give the same UUID |
| v4 | 122 random bits | No | General unique IDs, order numbers, tokens |
| v6 | Like v1 but reordered | Yes | Upgrading systems that use v1 |
| v7 | 48-bit Unix milliseconds + 74 random bits | Yes | Database primary keys, logs, events |
Swipe sideways to see the whole table →
The version is the first digit of the third group: …-4xxx-… is v4, …-7xxx-… is v7.
Inside a v7 UUID
The example from RFC 9562: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f
| Part | Size | Meaning |
|---|---|---|
| 017f22e2-79b0 | 48 bits | Milliseconds since 1 Jan 1970 UTC: 22 Feb 2022 19:22:22 UTC |
| 7 | 4 bits | Version number (7) |
| cc3 | 12 bits | Random, or a counter that keeps order within one millisecond |
| 9 (bits 10xx) | 2 bits | RFC 9562 variant |
| 8c4-dc0c0c07398f | 62 bits | Random |
Real-world examples
Primary keys for an orders table
Use v7 instead of v4: new rows always land at the end of the B-tree index, so inserts are faster and index pages split less, and IDs can still be created in the application without asking the database.
Seed data
Need 500 IDs for a seed file? Set the count to 500, generate, then download the .txt: one UUID per line, ready to paste into a script.
GUIDs for Windows or .NET config
Turn on uppercase and braces to get the {3F2504E0-4F89-41D3-9A0C-0305E82C3301} form used by the registry and .csproj files.
When was this record created?
Paste a v7 ID from your logs into the inspector: it reads the 48-bit timestamp and shows the exact time, no database query needed.
Common problems and fixes
- Inserts slow down with v4 UUID primary keys.
- Random values land all over the index. Switch to v7 (or ULID) so new values always increase.
- “Not a valid UUID”.
- It needs exactly 32 hex digits; with hyphens they must be grouped 8-4-4-4-12. A urn:uuid: prefix and braces are accepted.
- Worried about v4 collisions.
- With 122 random bits you'd need about 2.7 × 10^18 IDs before the chance of a single duplicate reaches 50%. Real-world risk comes from poor random generators, not the UUID format.
- Using a UUID as a secret (password-reset link).
- v4 from crypto.randomUUID is unguessable enough, but v1, v6 and v7 reveal their creation time and are partly predictable. Use 128 purely random bits for secret tokens.
- The system only accepts lowercase.
- RFC 9562 recommends lowercase output and case-insensitive comparison; turn off UPPERCASE before copying.
Why UUIDs practically never collide
A v4 UUID has 2^122 (about 5.3 × 10^36) possible values. Even if everyone on Earth generated a billion of them, the odds of a duplicate would remain vanishingly small. That's why many machines can create IDs independently without a central server handing out numbers.
This tool uses crypto.randomUUID (or crypto.getRandomValues in older browsers), the operating system's cryptographic random source, never Math.random.
UUID v7 joined the standard in 2024
RFC 9562 (May 2024) replaced RFC 4122 and added versions 6, 7 and 8. v7 was quickly adopted by PostgreSQL 18 and many libraries and ORMs because it combines the ordering of auto-increment IDs with the anywhere-generation of UUIDs.
Glossary
- UUID / GUID
- A 128-bit unique identifier; GUID is Microsoft's name for the same thing.
- Version
- How the UUID was made, stored in the top four bits of the third group.
- Variant
- The bit layout of the UUID; today's standard is the RFC 9562 variant (bits 10xx).
- Nil UUID
- 00000000-0000-0000-0000-000000000000, used as an “empty” value.
- Max UUID
- ffffffff-ffff-ffff-ffff-ffffffffffff, the largest value, introduced in RFC 9562.
- Primary key
- The column that uniquely identifies each row in a database table.
Frequently asked questions
Should I use v4 or v7?
v7 for primary keys or anything that should sort by time; v4 when you just need a unique value and don't want to reveal when it was created.
Can UUIDs collide?
In theory, yes; in practice, almost never. With v4 you'd need billions of billions of IDs before it's a concern, and v7 can only collide within the same millisecond.
Are the UUIDs stored anywhere?
No. They're generated with your browser's random source and exist only on your page.
Are GUIDs and UUIDs different?
They're the same 128-bit standard. Microsoft calls them GUIDs and often writes them uppercase in braces; the bits are identical.
Can I get a timestamp out of a v4 UUID?
No, v4 is entirely random. Only v1, v6 and v7 contain a time.
Why do v7 IDs generated together start the same?
IDs created in the same millisecond share the 48-bit timestamp; the counter after it increases so they still sort in the right order.
Ratings and comments
Loading…