UUID Generator

What a UUID Is and Why Developers Use Them Constantly

A UUID (Universally Unique Identifier) is a 128-bit number formatted as a 32-character hexadecimal string in five groups separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. An example looks like: a7fbc1d2-4e38-4b9f-8c6a-1d2e3f4a5b6c. The defining property is that it's generated to be unique across all space and time without requiring central coordination — no registry, no database lookup, no server round-trip needed to guarantee uniqueness.

This makes UUIDs the standard solution for generating unique identifiers in distributed systems, databases, APIs, and any context where multiple independent sources might need to create IDs simultaneously without conflicting.

UUID v4: The Most Commonly Used Version

There are several UUID versions with different generation strategies. UUID v4 is the most widely used in modern software because it's generated from random bits alone. Version 4 generates 122 random bits (the remaining 6 bits encode the version and variant), formats them into the standard UUID structure, and produces a result that has no connection to any machine identifier, timestamp, or sequential counter. This makes v4 UUIDs both unpredictable and privacy-preserving.

Our generator produces UUID v4 values using your browser's crypto.getRandomValues() API, which provides cryptographically secure randomness. The generated UUID is computed locally — nothing is sent to any server.

Where UUIDs Are Used in Software Development

Database Primary Keys

The traditional approach to database primary keys is an auto-incrementing integer — the first record gets ID 1, the second gets ID 2, and so on. This works well for centralized databases but breaks down in distributed systems where multiple servers or services might insert records simultaneously. If two separate services both try to create a record and both receive ID 1, you have a conflict.

UUIDs solve this by letting each service generate its own ID without coordination. The generated UUID is statistically guaranteed to be unique even across separate systems. Many modern ORMs and databases (PostgreSQL, MongoDB, newer MySQL versions) support UUID primary keys natively. The trade-off is that UUID columns are larger than integer columns (16 bytes vs 4 bytes for INT) and less sequential, which affects certain index performance characteristics — but for most applications the distributed uniqueness guarantee outweighs these considerations.

REST API Resources

API endpoints that expose resources through URLs often use UUIDs as resource identifiers: /api/users/a7fbc1d2-4e38-4b9f-8c6a-1d2e3f4a5b6c. Unlike sequential integer IDs, UUIDs don't leak information about the total number of records in your database (anyone who sees ID 1247 knows you have at least that many records), don't let users enumerate resources by incrementing the ID, and don't expose the order in which resources were created. These properties are useful for privacy and security.

Session Tokens and Correlation IDs

User session tokens, authentication tokens that aren't JWT, CSRF tokens, and distributed tracing correlation IDs are all commonly implemented as UUIDs. For these use cases, the unpredictability of UUID v4 is essential — a predictable token could be guessed or brute-forced. The 122 bits of entropy in a UUID v4 make it computationally infeasible to enumerate or predict.

Client-Side ID Generation

In applications that support offline functionality, UUIDs enable client-side ID generation before network connectivity is available. A mobile app can create records with UUID primary keys while offline, then sync them to the server when connectivity is restored — without any risk of ID collisions with records created by other clients or by the server during the offline period.

UUID Format and Variants

A standard UUID is represented as: 8-4-4-4-12 hexadecimal characters separated by hyphens. The 13th character (the first character of the third group) encodes the version: for UUID v4, this is always the digit 4. The 17th character (the first character of the fourth group) encodes the variant and is always 8, 9, a, or b for standard UUIDs.

UUIDs are case-insensitive — A7FBC1D2-4E38-4B9F-8C6A-1D2E3F4A5B6C and a7fbc1d2-4e38-4b9f-8c6a-1d2e3f4a5b6c are the same value. Most systems store them in lowercase by convention. Some systems store UUIDs without hyphens as a 32-character hex string; the values are equivalent, just different string representations.

UUID vs. CUID vs. nanoid: Choosing the Right Unique ID Format

UUID v4 is the most portable format — it's standardized, broadly supported across languages and databases, and immediately recognizable to other developers. However, alternatives exist for specific use cases.

CUID and CUID2 are formats designed for sequential-ish generation that improves database index performance compared to random UUIDs, while remaining unique across distributed systems. They're useful when database insertion performance matters more than strict standardization.

nanoid is a smaller package that generates compact URL-safe random strings. At default settings it produces a 21-character string with comparable collision resistance to a UUID v4. Useful when URL readability or shorter IDs matter and full UUID compatibility isn't required.

For most applications where compatibility, clarity, and standardization matter — UUIDs remain the default choice, and UUID v4 the default version.