About UUID Generator
Generate UUID v1, v4, and v5 identifiers instantly. Create single or bulk UUIDs with one click. Free UUID generator for developers — copy results in uppercase or lowercase.
How to use
- Pick the UUID version. v4 (random) is the safe default for primary keys, API resource IDs, and correlation IDs — 122 random bits, no metadata leaks. v1 (timestamp + MAC address) is sortable by time but exposes when and where it was generated; avoid for anything user-facing. v5 (namespace + name + SHA-1) is deterministic — same input always produces the same UUID, useful for stable IDs derived from external identifiers like email addresses or URLs. Example v4:
9f8b8c7e-4d3a-4f5b-9c2d-1e8a7b6c5d4e (note the 4 at position 13 marking the version).
- Consider UUID v7 for new projects. Defined in RFC 9562 (May 2024), v7 prefixes a 48-bit Unix millisecond timestamp followed by random bits. This gives you v4-style privacy (no MAC address) plus natural time-ordering — critical for B-tree index performance in PostgreSQL, MySQL, and most SQL databases. Random v4 inserts cause page splits and index fragmentation at scale; v7 inserts append to the end of the index like an autoincrement int. Sample v7:
018f5b9c-1234-7abc-89de-f0123456789a.
- For UUID v5, supply a namespace UUID and a name string. Standard namespaces from RFC 4122 Appendix C: DNS (
6ba7b810-9dad-11d1-80b4-00c04fd430c8), URL (6ba7b811-...), OID, and X.500. v5(DNS, "example.com") always returns cfbff0d1-9375-5685-968a-48ce8b15ae17. Same input + same namespace = same UUID, every time, on every machine. Use this when you need to derive a stable internal ID from a non-UUID external key without keeping a lookup table.
- Set the batch count for bulk generation. Useful for database seeding, test fixture creation, or pre-allocating IDs in a migration script. Each UUID in the batch is independently generated, so collision probability across the batch is negligible — for v4, you would need to generate 2.71 quintillion UUIDs before there is a 50% chance of a single collision (the birthday problem on 122 bits).
- Toggle case if your system requires it. RFC 4122 specifies lowercase as canonical (
9f8b8c7e-...) and most modern stacks emit lowercase. Some legacy systems and Microsoft tooling default to uppercase or wrap UUIDs in braces ({9F8B8C7E-...}). Database type matters too: PostgreSQL uuid is canonical lowercase, but stored as 16 bytes regardless; SQL Server uniqueidentifier uses uppercase by default but is byte-order sensitive in indexes.
- Generation runs locally via
crypto.getRandomValues() for v4 (CSPRNG, suitable for security-adjacent contexts) and SHA-1 hashing for v5 (cryptographically broken for collision resistance, but still acceptable for UUID v5 because the output is intentionally truncated and namespace-scoped). No bytes leave your browser — safe for generating IDs that will end up in production secrets management or seed scripts.
- Click any UUID to copy a single value, or Copy All for the batch as newline-delimited text — paste straight into a Postgres
INSERT, a JSON fixture, or a YAML config. Do not use UUIDs as authentication tokens or API keys: while v4 has 122 bits of randomness, dedicated token formats add expiration, scope, and prefix metadata (sk_live_, ghp_, etc.) that UUIDs lack. UUIDs are resource identifiers, not credentials.
Frequently asked questions
UUID v1 vs v4?
UUID v1 embeds a timestamp (the current time in 100-nanosecond intervals since October 15, 1582) and the MAC address of the generating machine. This makes v1 UUIDs partially sortable by creation time but also leaks information about when and where they were created. UUID v4 is generated entirely from cryptographically secure random numbers — 122 of its 128 bits are random, with 6 bits reserved for version and variant markers. V4 is the most widely used version because it is simple, private, and has no external dependencies (no MAC address, no clock).
When to use UUID v5?
Use UUID v5 when you need the same input to always produce the same UUID — this is called deterministic or reproducible ID generation. V5 takes a namespace UUID and a name string, hashes them together with SHA-1, and truncates the result to 128 bits. Common use cases include converting email addresses into consistent user IDs across systems, generating stable identifiers for URLs or domain names, and creating reproducible test fixtures. UUID v3 works identically but uses MD5 instead of SHA-1 — prefer v5 since SHA-1 is the stronger hash.
Can two UUIDs collide?
For UUID v4, the probability of collision is astronomically low. With 122 random bits, there are 5.3 x 10^36 (5.3 undecillion) possible UUIDs. You would need to generate approximately 2.71 quintillion (2.71 x 10^18) UUIDs before there is a 50% probability of a single collision — this is known as the birthday problem threshold. To put that in perspective, if every person on Earth generated 1 billion UUIDs per second, it would take about 100 years to reach that threshold. In practice, UUID collisions are treated as impossible.
UUID vs auto-increment?
Auto-increment IDs (1, 2, 3...) are simpler, smaller (4-8 bytes vs 16 bytes), and produce naturally ordered primary keys that are efficient for B-tree indexes. However, they expose business information (competitor can estimate your total user count), enable enumeration attacks (scraping /users/1, /users/2, /users/3...), and require a single authority to assign IDs (problematic in distributed systems). UUIDs solve all three problems: they are unguessable, reveal no information about total count or creation order, and can be generated independently by any node without coordination.
What format is a UUID?
A UUID is a 128-bit identifier represented as 32 hexadecimal digits arranged in five groups separated by hyphens in the pattern 8-4-4-4-12 (e.g., 550e8400-e29b-41d4-a716-446655440000). The 13th character (first digit of the third group) indicates the version (1, 4, or 5), and the 17th character indicates the variant (8, 9, a, or b for RFC 4122 UUIDs). The total string length is always 36 characters including hyphens, or 32 characters without.
What is UUID v7 and should I use it?
UUID v7 is a newer format defined in RFC 9562 (published May 2024) that combines the best of v1 and v4. The first 48 bits encode a Unix timestamp in milliseconds, and the remaining bits are random. This gives v7 UUIDs natural time-sortability (great for database index performance) without exposing MAC addresses like v1. UUID v7 is gaining adoption in modern databases (PostgreSQL, CockroachDB) and is an excellent choice for new projects where time-ordered IDs improve query performance.
How do UUIDs affect database performance?
Random UUIDs (v4) can cause performance issues with B-tree indexes in traditional databases because new inserts land at random positions in the index, causing page splits and fragmentation. This is most noticeable at very high insert rates (thousands per second) on tables with millions of rows. Mitigations include using UUID v7 (time-ordered), storing UUIDs as binary(16) instead of char(36) to save storage, or using databases with LSM-tree storage engines (like CockroachDB or ScyllaDB) where random inserts are less costly.
Can I use UUIDs as API keys or authentication tokens?
UUID v4 values have 122 bits of randomness, which provides reasonable unpredictability. However, dedicated API key and token formats are preferred for authentication because they can include additional properties like expiration timestamps, scope restrictions, and checksums for validation. For session tokens, use your framework's built-in session management. For API keys, consider formats that include a prefix (e.g., sk_live_...) for easy identification. UUIDs are best used as resource identifiers, not secrets.
Part of ToolFluency’s library of free online tools for Developer Tools. No account needed, no data leaves your device.