UUID Generator

What this tool does

UUID Generator creates universally unique identifiers following RFC 9562, the 2024 standard that replaced RFC 4122. Generate up to 10,000 random v4 or time-ordered v7 UUIDs at once, derive deterministic v5 and v3 UUIDs from names, and decode any UUID to see its version, variant and embedded timestamp.

Databases, APIs and distributed systems need identifiers that can be created on any machine without asking a central server for the next number. A UUID is a 128-bit value written as 32 hexadecimal digits in five groups (8-4-4-4-12). Picking the wrong version matters: random v4 values scatter inserts across a B-tree index, while name-based versions repeat the same output for the same input, which is exactly what you want for idempotent imports and wrong for session tokens.

This generator implements the versions defined in RFC 9562. Version 4 uses 122 random bits from the Web Crypto API. Version 7 puts a 48-bit Unix millisecond timestamp in front, plus a 12-bit counter so IDs created in the same millisecond still sort correctly. Version 1 uses a 60-bit Gregorian timestamp with a random node ID instead of your network card address. Versions 5 and 3 hash a namespace and a name with SHA-1 or MD5. Everything is computed locally in your browser.

How to use UUID Generator

1. Choose the UUID version in Options. Version 4 is the safe default; pick version 7 for database primary keys.
2. Set How many (up to 10,000). For version 5 or 3, pick a namespace and type one name per line instead.
3. Choose the Output format: one per line, comma separated, JSON array, quoted lines or a SQL IN list.
4. Toggle Uppercase, Hyphens or braces to match the style your code expects, such as {GUID} for .NET or the registry.
5. Click Generate (or press Ctrl + Enter) for a fresh batch, then copy or download the list.
6. Paste any UUID into Inspect a UUID to read its version, variant, integer value and embedded time.

Tips for better results

• Prefer v7 for primary keys in PostgreSQL, MySQL and SQL Server: new rows land at the end of the index instead of splitting random pages.
• Use v5 when the same input must always map to the same UUID, for example deriving an ID from a URL with the URL namespace.
• Store UUIDs as a native uuid or 16-byte binary column rather than a 36-character string; it halves storage and speeds up comparisons.
• The nil UUID (all zeros) is handy as an explicit “no value” sentinel in tests and fixtures.

Common use cases

• Seeding test data and fixtures with realistic primary keys.
• Creating correlation or request IDs for logs and tracing.
• Generating stable IDs for documents imported from another system with v5.
• Checking whether an ID from a third-party API is v4, v7 or v1 and when it was created.

Common mistakes to avoid

• Treating a UUID as a secret. v1 and v7 reveal their creation time, and none of them replace a proper access token.
• Mixing uppercase and lowercase forms in a case-sensitive string column, which creates apparent duplicates. RFC 9562 recommends lowercase output.
• Using v3 for new designs; MD5 is retained only for compatibility, so choose v5 unless a spec requires v3.
• Sorting v4 UUIDs and expecting creation order. Only time-based versions such as v7 sort chronologically.