Loading...
UUID v4 (Random) — 122 bits of cryptographic randomness. Most widely used version. No timestamp, no MAC address, no ordering. Collision probability: ~1 in 2.71 quintillion.
Pro tip
Building APIs? Git AutoReview catches missing ID validation, UUID format errors, and collision-prone patterns in your PRs automatically.
A UUID (Universally Unique Identifier) is a 128-bit number formatted as 32 hex digits in five groups separated by hyphens: 8-4-4-4-12. The standard is defined in RFC 9562 (which superseded RFC 4122 in 2024). Microsoft calls them GUIDs (Globally Unique Identifiers) but the format is identical.
The practical value of UUIDs is that you can generate them independently on any machine without coordination, and the probability of collision is negligible. A UUID v4 has 122 random bits, which means you could generate a billion per second for 85 years before reaching a 50% chance of one duplicate.
UUID v4 is the default choice for most applications. It uses pure randomness, needs no external state, and is supported everywhere from JavaScript to Python to Go. If you need IDs that sort chronologically (useful for database primary keys where index performance matters), UUID v7 is the modern standard from RFC 9562. It embeds a millisecond timestamp in the first 48 bits while keeping the rest random.
UUID v1 is the legacy timestamp format that includes a MAC address component. It works but leaks information about when and where the ID was created. UUID v5 generates deterministic IDs by hashing a namespace and name with SHA-1 — useful when you need the same input to always produce the same UUID.
The choice comes down to one question: do your IDs need to sort by creation time? If yes, use v7. The timestamp prefix means newer IDs are always lexicographically greater than older ones, which keeps B-tree indexes compact and reduces page splits in PostgreSQL, MySQL, and similar databases. If ordering does not matter, v4 is simpler and more widely supported.
Yes. GUID is Microsoft terminology for the same 128-bit identifier format. In .NET you call Guid.NewGuid(), in JavaScript you call crypto.randomUUID(), and both produce RFC-compliant version 4 UUIDs. The only cosmetic difference is that Microsoft tools sometimes wrap GUIDs in curly braces like {550e8400-e29b-41d4-a716-446655440000}.
Most languages have built-in or standard library support. JavaScript: crypto.randomUUID() (browser and Node.js 19+). Python: import uuid; uuid.uuid4(). Go: google/uuid package. Java: java.util.UUID.randomUUID(). For UUID v7, the uuid npm package (v10+) supports it via import { v7 as uuidv7 } from 'uuid'.
A UUID (Universally Unique Identifier) is a 128-bit label used to identify information in computer systems. The format is 8-4-4-4-12 hex digits, for example 550e8400-e29b-41d4-a716-446655440000. UUIDs are also called GUIDs (Globally Unique Identifiers) in Microsoft ecosystems. The chance of two randomly generated v4 UUIDs colliding is roughly 1 in 2.71 quintillion.
For most applications, UUID v4 (random) is the right choice — it is the most widely adopted and requires no external state. If you need time-sortable IDs for database primary keys, UUID v7 is the modern standard defined in RFC 9562. Use v5 when you need deterministic IDs derived from a name and namespace (like generating the same UUID from the same URL every time).
They are the same thing. UUID is the standard term from RFC 9562. GUID (Globally Unique Identifier) is Microsoft's name for UUIDs, used in Windows, .NET, and SQL Server. The format, generation algorithms, and collision properties are identical.
Not replacing, but supplementing. UUID v7 adds a timestamp prefix so IDs sort chronologically, which improves database index performance by 20-40% compared to random v4 IDs. RFC 9562 recommends v7 for new systems that need time ordering. For pure randomness without ordering requirements, v4 remains the standard choice.
Yes. This tool runs entirely in your browser using the Web Crypto API (crypto.randomUUID and crypto.getRandomValues), which provides cryptographically secure random numbers. No UUIDs are sent to any server or stored anywhere.
Theoretically yes, practically no. A UUID v4 has 122 random bits, giving 5.3 undecillion possible values. You would need to generate 2.71 quintillion UUIDs before having a 50% chance of one collision. For context, generating a billion UUIDs per second would take 85 years to reach that threshold.
The nil UUID is 00000000-0000-0000-0000-000000000000 — all zeros. It is defined in RFC 9562 as a special UUID that represents 'no value' or 'unknown'. It is commonly used as a default or placeholder in databases and APIs where a UUID field is required but no real value exists yet.
In modern browsers and Node.js 19+, use crypto.randomUUID() which returns a v4 UUID string. For older environments, use the uuid npm package: import { v4 as uuidv4 } from 'uuid'; const id = uuidv4();
Developer Toolkit by Git AutoReview
Free tools for developers. AI code review for teams.