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
- Select the UUID version you need from the dropdown. UUID v4 (random) is the most commonly used version — it generates identifiers using cryptographically secure random numbers and is the standard choice for database primary keys, API resource IDs, session tokens, and message correlation IDs. UUID v1 (timestamp-based) is useful when you need time-sortable IDs. UUID v5 (name-based) is used when you need deterministic IDs derived from a namespace and input string.
- For UUID v5, enter a namespace UUID and a name string to generate a deterministic identifier. The namespace scopes the name so that the same name in different namespaces produces different UUIDs. Standard namespaces include DNS (for domain names), URL (for web addresses), OID (for ISO object identifiers), and X.500 (for directory names). For example, using the DNS namespace with 'example.com' always produces the same UUID — useful for generating consistent IDs from external identifiers.
- Choose how many UUIDs to generate in a single batch, from 1 to 100 or more. Bulk generation is useful for pre-allocating IDs for database seeding scripts, test fixtures, or migration tools. Each UUID in the batch is independently generated with full randomness (for v4) or computed from sequential inputs (for v1/v5). The entire batch generates instantly in your browser.
- Click any individual UUID to copy it to your clipboard, or use the 'Copy All' button to grab the entire batch as a newline-separated list. UUIDs are generated in lowercase by default (the canonical format per RFC 4122), but you can toggle to uppercase if your system requires it. The copied output is plain text, ready to paste into code, SQL statements, configuration files, or API requests.
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.