UUID Generator
Cryptographically secure · Web Crypto API · 100% local
Ready
How This UUID Generator Works
A UUID is 128 bits written as 32 hex digits in an 8-4-4-4-12 pattern, such as 550e8400-e29b-41d4-a716-446655440000. In a version 4 UUID, 122 of those bits are random: the first digit of the third group is always 4 and the first digit of the fourth group is 8, 9, a or b. Generate v4, v7 or v1 UUIDs above, up to 100 at a time.
Pick a version, a count up to 100 and a format, then click Generate. Every UUID is created in your browser from crypto.getRandomValues(), the operating system's cryptographic random source, not from Math.random(). Nothing is sent to a server, and the list is gone when you close the page.
How to Read a UUID
Two example values, one v4 and one v7 created at 12:00:00 UTC on 21 September 2026.
| Part | v4 example | v7 example | What it holds |
|---|---|---|---|
| Group 1 (8 digits) | a1b2c3d4 | 01a0c3d6 | v4: random. v7: the first 32 bits of the millisecond timestamp |
| Group 2 (4 digits) | e5f6 | 5a00 | v4: random. v7: the last 16 bits of the timestamp (01a0c3d65a00 = 1,789,992,000,000 ms) |
| Group 3, first digit | 4 | 7 | The version |
| Group 3, other 3 digits | 718 | c1e | Random |
| Group 4, first digit | a | 9 | The variant: 8, 9, a or b for RFC 9562 UUIDs |
| Rest (15 digits) | 93a-4b5c6d7e8f90 | f3b-2d4a6e8c0b17 | Random |
The nil UUID (all zeros) and the max UUID (all f) are special values and do not follow the version and variant rules.
Collision Odds in Numbers
The chance that at least two of n random v4 UUIDs are equal is about 1 − e−n²/(2 × 2122), the birthday problem.
| v4 UUIDs generated | Chance of any duplicate |
|---|---|
| 1 million | about 1 in 1025 |
| 1 billion | about 1 in 1019 |
| 1 trillion | about 1 in 10 trillion |
| 1 quadrillion (1015) | about 1 in 10.6 million |
| 1018 | about 9% |
| 2.71 × 1018 | about 50% |
2.71 × 1018 is what you get from a billion UUIDs every second for about 86 years. In practice, duplicates come from bugs, such as a weak random generator or a copied database row, not from chance.
v4, v7 or v1: Which to Pick
| Version | Contents | Sorts by time | Best for |
|---|---|---|---|
| v4 | 122 random bits | No | General IDs, public identifiers, anything that should not reveal when it was made |
| v7 | 48-bit Unix time in ms + 74 random bits | Yes | Database primary keys, event and log IDs |
| v1 | 60-bit time in 100 ns steps since 15 Oct 1582 + clock sequence + node | Not as text | Only legacy systems that expect it |
This page's v7 list is sorted within each batch, so values created in the same millisecond still come out in order. Its v1 values use a random node ID with the multicast bit set, as RFC 9562 allows, so they never contain your network card's MAC address. Keep in mind that v7 reveals its creation time to anyone who sees it.
Method and sources. Layout, version and variant bits follow RFC 9562 (May 2024), which replaced RFC 4122. Collision odds use the birthday approximation 1 − e−n²/2N with N = 2122, computed in Node.js. The v7 example timestamp was converted in Node.js. Database notes: PostgreSQL 18 documentation (gen_random_uuid, uuidv4, uuidv7) and MySQL 8.0 documentation (UUID_TO_BIN).
UUID Guide
UUID (Universally Unique Identifier), also known as GUID (Globally Unique Identifier) in Microsoft terminology, is a 128-bit label standardized by RFC 9562 (formerly RFC 4122). It looks like
550e8400-e29b-41d4-a716-446655440000, 32 hexadecimal digits in five groups separated by hyphens (8-4-4-4-12). A version 4 UUID has 122 random bits, so there are about 5.3 × 10^36 possible v4 values. The probability of generating two identical UUIDs is astronomically small: for v4, generating a billion UUIDs per second for about 86 years, the probability of a single collision is roughly 50%. UUIDs are used as database primary keys, session tokens, file names, message IDs, and API object identifiers.UUID v4 is completely random: 122 bits from a cryptographically secure random source, 6 bits for version and variant markers. No information about the generating machine or time. The most widely used version. UUID v7 is a 2024 standard (RFC 9562) that embeds a Unix millisecond timestamp in the first 48 bits, making them sortable chronologically. The remaining bits are random. This makes it ideal for database primary keys because sequential inserts benefit from B-tree index performance. UUID v1 embeds a 100-nanosecond timestamp since October 1582 plus the MAC address of the generating machine. Sortable but leaks system information: avoid in new applications.
For most use cases: UUID v4 is the safe default. Completely random, no information leakage, supported natively in all databases, ORMs, and languages. Use UUID v7 for database primary keys where you want chronological sortability: it dramatically improves index performance in PostgreSQL, MySQL/InnoDB, and SQL Server because sequential inserts avoid page splits. Prisma, Hibernate, and other ORMs are adding v7 support. Avoid UUID v1 in new code because it exposes your MAC address. If you are on PostgreSQL, the built-in
gen_random_uuid() generates v4. PostgreSQL 18 and later also have a built-in uuidv7(); on older versions use an extension or generate v7 in the application.ULID (Universally Unique Lexicographically Sortable Identifier) is an alternative to UUID designed for sorting. A ULID looks like
01ARZ3NDEKTSV4RRFFQ69G5FAV, 26 characters of Crockford Base32 encoding a 48-bit timestamp plus 80 bits of randomness. Advantages over UUID: lexicographically sortable, URL-safe with no special characters, slightly more compact (26 vs 36 chars). Disadvantages: not standardized by an RFC, less tooling support. UUID v7 largely solves the sortability problem that made ULID attractive, so new projects should prefer UUID v7 over ULID for better ecosystem support.UUIDs as primary keys have significant advantages: globally unique without coordination between servers (no auto-increment conflicts in distributed systems), IDs do not expose row count or creation order, safe to generate application-side before insert. The main disadvantage of UUID v4 is index fragmentation: random UUIDs cause non-sequential inserts into B-tree indexes, leading to page splits and bloat. Solutions: use UUID v7 (time-ordered), store as
UUID type (not VARCHAR(36)) for 16 bytes vs 36 bytes, or use InnoDB's clustered index carefully. PostgreSQL: UUID type natively. MySQL has no native UUID type: store it as BINARY(16) with UUID_TO_BIN() (MySQL 8.0 and later). MariaDB 10.7 and later has a native UUID type. MongoDB uses its own ObjectID format which is similar in concept to UUID v7.JavaScript/Node.js:
crypto.randomUUID() (native, v4) or the uuid package for all versions. Python: import uuid; str(uuid.uuid4()). Go: github.com/google/uuid package. Java: UUID.randomUUID().toString(). C#: Guid.NewGuid().ToString(). PHP: Str::uuid() (Laravel) or ramsey/uuid. Ruby: SecureRandom.uuid. Rust: uuid crate. PostgreSQL: gen_random_uuid() for v4, uuid_generate_v4() with uuid-ossp extension. MySQL 8+: UUID() for v1, or install UDF for v4/v7.Standard: the canonical UUID format with lowercase hex and hyphens:
550e8400-e29b-41d4-a716-446655440000. UPPERCASE: same format but uppercase: 550E8400-E29B-41D4-A716-446655440000. Some older Windows/Microsoft APIs expect uppercase GUIDs. No-dashes: hyphens removed, 32 hex characters: 550e8400e29b41d4a716446655440000. More compact, often used in URLs or when the 36-char format is inconvenient. Braces: Windows GUID format with curly braces: {550e8400-e29b-41d4-a716-446655440000}. Used in Windows Registry, COM interfaces, and .NET. URN: RFC 4122 URN format: urn:uuid:550e8400-e29b-41d4-a716-446655440000. For XML, RDF, and formal namespace contexts.UUID v4 uniqueness relies on the quality of the random number generator. With a cryptographically secure source (like the Web Crypto API used here), generating 1 billion UUIDs per second for 86 years only gives a 50% chance of a single collision. In practice, UUID v4 collisions are effectively impossible at any realistic scale. UUID v1 uniqueness depends on the MAC address plus timestamp to the 100-nanosecond precision, which guarantees uniqueness on a single machine. The risk is if MAC addresses are faked or clocks run backwards. UUID v7 uses millisecond timestamps plus random bits: within the same millisecond, multiple UUIDs are distinguished by random bits, making collisions equally improbable as v4.
A UUID has 128 bits total, displayed as 32 hex characters in groups:
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M position indicates the version (1, 4, 7, etc.). The N position indicates the variant: bits 10 mean RFC 4122 (the standard). For UUID v4: 122 bits are random, 4 bits are the version (0100 = 4), 2 bits are the variant (10). For UUID v7: bits 0-47 are a Unix timestamp in milliseconds, bits 48-51 are the version (0111 = 7), bits 52 to 63 are random, bits 64 and 65 are the variant (10), and bits 66 to 127 are random. You can tell a UUID's version by looking at the first character of the third group: v4 starts with 4, v7 starts with 7, v1 starts with 1.The nil UUID is all zeros:
00000000-0000-0000-0000-000000000000. It represents the absence of a UUID, similar to null or None. Uses: default value for UUID fields before a real ID is assigned, placeholder in data structures, sentinel value in protocols. The max UUID is all ones (hex ffffffff-ffff-ffff-ffff-ffffffffffff), sometimes used as a maximum boundary in range queries. RFC 9562 also defines a "nil" and "max" UUID as official special values. When querying by UUID in SQL, always use the database-native UUID type rather than string comparison to ensure proper index usage.For RFC 9562 UUIDs of versions 1 to 8, use
^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ with the case-insensitive flag. To accept only v4, replace [1-8] with 4. The nil UUID fails this pattern on purpose, so check for it separately if you allow it. In most languages a UUID parser is safer than a regex, for example uuid.UUID(s) in Python.A v4 UUID from a cryptographic generator, like the ones here, has 122 random bits, which is hard to guess, and many systems use it that way. Do not use v1 or v7 for secrets: their time field makes part of the value predictable. For API keys, 128 bits or more of random data encoded in Base64url or hex is the more common choice, and it should be stored hashed on the server.