Use UUID v4 when you need fully random, unpredictable IDs with no embedded metadata — for example, session tokens or public-facing identifiers. Use UUID v7 when sortability matters, especially for database primary keys. v7 UUIDs are monotonically increasing, which avoids B-tree index fragmentation in SQL databases and generally yields better INSERT performance at scale.

In practice, yes. A UUID v4 has 122 random bits (≈5.3 × 10³⁶ possibilities). To have a 1% chance of a collision, you would need to generate roughly 2.6 × 10¹⁸ UUIDs — far beyond any real-world application. However, do not use UUIDs as cryptographic secrets; they are not secrets, just unique labels.

Yes. The hyphenless format (32 hex characters) is semantically identical and often used in storage-constrained environments. Toggle "With hyphens" off in this tool to generate the compact format. Ensure your validation code handles both forms.

The standard format is 8-4-4-4-12 hex characters: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The 13th character (M) is the version (4 or 7). The 17th character (N) is 8, 9, a, or b (indicating the RFC 4122 variant).

Yes. This tool uses the Web Crypto API (crypto.getRandomValues) via the uuid npm package, which provides cryptographically secure randomness — the same source used by the operating system's random number generator. No data is sent to any server.

Yes. The first 12 hex characters of a UUID v7 encode a 48-bit Unix millisecond timestamp. This tool decodes and displays that timestamp next to each v7 UUID in the results list. In code: parseInt(uuid.replace(/-/g, '').substring(0, 12), 16) gives you the milliseconds since the Unix epoch.