// generators
UUID Generator.
Generate UUIDs locally using crypto.getRandomValues and crypto.randomUUID. Bulk modes, hyphenation, and uppercase.
UUIDs
What Are UUIDs?
UUIDs, or Universally Unique Identifiers, are 128-bit values designed to be practically unique across all space and time. When you generate a UUID, the probability that another system, anywhere in the world, has generated the same identifier at the same time is vanishingly small. This makes UUIDs an indispensable tool in modern software development, where applications running on different servers, databases, and services need to reference entities without the risk of ID collisions.
Unlike sequential integer IDs that depend on a single database to assign values, UUIDs can be generated independently by any system without coordination. A mobile app can create a UUID for a new record offline, and when that record syncs to the server, it is guaranteed not to conflict with any existing ID. This decentralized approach to identity is critical in distributed architectures, microservices, and offline-first applications where a central authority for ID assignment is not always available.
UUID Formats and Structure
A UUID is represented as a 32-character hexadecimal string displayed in five groups separated by hyphens, following the pattern xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. For example, f47ac10b-58cc-4372-a567-0e02b2c3d479 is a valid UUID. The 128 bits of the UUID encode version information, variant information, and unique data. The version number occupies four bits of the third group, and the variant occupies the first two bits of the fourth group. This structure allows software to parse and validate UUIDs by examining these embedded fields.
The most common representations are lowercase with hyphens, but uppercase variants also exist. The hyphens are purely cosmetic and do not affect the underlying value. Most APIs and databases accept UUIDs in either case, with or without hyphens, though the canonical form includes both. When storing UUIDs in databases, you can choose between storing them as a native UUID type (which is space-efficient and index-friendly) or as a 36-character string, depending on your database engine and performance requirements.
UUID v4: Random Generation
Version 4 UUIDs are generated using cryptographically secure random numbers. Every bit of the UUID except for the version and variant fields is filled with random data. This approach produces identifiers that have no meaningful structure or ordering, but they are statistically unique to an extraordinary degree. The chance of two independently generated v4 UUIDs colliding is approximately 1 in 2122, which is so remote that it will never occur in practice for any real-world application.
UUID v4 is the right choice when you need a simple, unpredictable identifier with no relationship to time or sequence. It is widely used for generating session tokens, temporary access keys, one-time verification codes, and any scenario where the ID itself should not reveal information about when it was created or how many records exist. The tradeoff is that random UUIDs are not sortable by creation time, which can cause performance issues with certain database indexes.
UUID v7: Time-Ordered Generation
Version 7 UUIDs address the sorting limitation of v4 by embedding a Unix timestamp in the most significant bits of the identifier. The first 48 bits represent milliseconds since the Unix epoch, followed by random bits that ensure uniqueness within the same millisecond. Because the timestamp occupies the leading bits, v7 UUIDs sort naturally in chronological order. This property makes them ideal for primary keys in databases, where insertion order matters for index performance.
When you insert rows with sequentially ordered IDs, most database engines can append them to the end of a B-tree index rather than splitting pages. This reduces fragmentation, improves write throughput, and makes range queries by time efficient. UUID v7 gives you the decentralization benefits of traditional UUIDs while retaining the insertion-order performance advantages of sequential integer IDs. The v7 format was standardized in RFC 9562 and is rapidly gaining adoption across modern frameworks and databases.
When to Use Each Version
Choose UUID v4 when unpredictability matters more than ordering. Security tokens, CSRF tokens, and temporary identifiers are good candidates for v4 because the random nature of the ID makes it harder to guess or enumerate. If you do not need to sort by creation time and your database does not benefit from ordered inserts, v4 is the simpler option.
Choose UUID v7 when you need time-ordered identifiers for database primary keys, event tracking, or log correlation. If your application creates many records per second and your database uses B-tree indexes, v7 will significantly outperform v4 in terms of write performance and index efficiency. v7 also makes it trivial to extract the creation timestamp from an ID, which is useful for debugging and audit trails.
Common Use Cases
UUIDs are used as primary keys in databases where data is sharded, replicated, or synchronized across multiple systems. They allow each system to generate new records independently without waiting for a central server to assign an ID. This is essential for distributed databases like Cassandra, Couchbase, and DynamoDB, where each node must be able to write data autonomously.
Session management is another primary use case. When a user logs into a web application, the server generates a UUID to represent that session. The UUID is sent to the client as a cookie and returned with each subsequent request. Because UUIDs are unique and unpredictable, they prevent session hijacking and enumeration attacks that would be trivial with sequential session IDs.
API request tracking relies on UUIDs to provide a correlation identifier that flows through every layer of a distributed system. When a request enters an API gateway, a UUID is generated and attached to the request context. As that request fans out to microservices, each service logs the UUID alongside its own operations. When something goes wrong, engineers can search for the UUID across all logs and trace the complete path of the request through the system.
Other common applications include event sourcing, where each event in an event store is identified by a UUID, and message queues, where each message is assigned a UUID to track delivery and deduplication. In IoT systems, devices generate UUIDs to uniquely identify sensor readings and telemetry data without depending on a centralized authority. The versatility of UUIDs makes them a foundational building block in virtually every modern software architecture.
FAQ
Should I use UUID v4 or v7 in 2026?
Use v7 for new database primary keys (sortable by time, better B-tree index performance); use v4 for security tokens/session IDs where unguessable randomness matters more than ordering.
How do I generate a UUID v7 in JavaScript?
Use the `uuid` npm package v9+: `uuid.v7()`; or roll your own with `crypto.randomUUID()` (v4) and a timestamp prefix for v7.
Is `Math.random()` good enough for generating UUIDs?
NO — `Math.random()` isn't cryptographically secure and can collide; always use `crypto.randomUUID()` (browser/Node 19+) or `uuid.v4()` library for real uniqueness.
What's the difference between UUID and GUID?
Practically nothing — GUID is Microsoft's term for UUID v1; modern GUIDs are UUID v4 (random). Same format, same spec, different name in different ecosystems.
Can I generate a UUID without dashes (32 hex chars only)?
Yes — `crypto.randomUUID().replace(/-/g, '')` in JS, or `uuid.uuid4().hex` in Python; some systems (older Oracle, certain DBs) require the dash-less format.