UUID Generator

A UUID (Universally Unique Identifier) is a 128-bit value used to uniquely identify information across systems without requiring a central coordinating authority. Also known as a GUID (Globally Unique Identifier) in Microsoft ecosystems, UUIDs are represented as 32 hexadecimal characters displayed in five groups separated by hyphens, following the pattern xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12).

The standard is defined in RFC 9562 (formerly RFC 4122) and provides a way to generate identifiers that are, for all practical purposes, unique without needing to check against a central registry. This makes UUIDs indispensable in distributed computing where multiple independent systems need to create identifiers that won't collide.

Version 1 (Time-based): Generated using the current timestamp and the MAC address of the machine. While this guarantees uniqueness, it leaks information about when and where the UUID was created, which can be a privacy concern. The timestamp is encoded as a 60-bit value representing 100-nanosecond intervals since October 15, 1582.

Version 4 (Random): The most widely used version. All 122 bits (excluding the 6 bits used for version and variant markers) are filled with cryptographically random data. This is the version generated by this tool. The probability of generating a duplicate is astronomically low — you'd need to generate about 2.71 quintillion UUIDs before reaching a 50% chance of a single collision.

Version 5 (Name-based, SHA-1): Deterministically generated from a namespace identifier and a name using SHA-1 hashing. Given the same namespace and name, the same UUID is always produced. This is useful when you need a consistent identifier derived from known input data, such as generating a UUID from a URL.

Version 7 (Time-ordered): A newer version introduced in RFC 9562 that encodes a Unix timestamp in the most significant bits, followed by random data. This gives UUIDs natural chronological sorting while preserving randomness — making them excellent as database primary keys because they maintain B-tree index locality and reduce page splits.

Database Primary Keys: UUIDs allow you to generate identifiers on the application side before inserting into the database. This simplifies distributed architectures where multiple services write to the same table, and it avoids exposing sequential IDs that reveal information about your data volume or creation order.

Distributed Systems: When multiple independent nodes need to generate unique identifiers without coordination, UUIDs are the standard solution. Microservices, event sourcing systems, and message queues all rely on UUIDs for correlation IDs and entity references across service boundaries.

Session and Token IDs: UUIDs serve as unguessable session identifiers, API tokens, and temporary resource handles. Their randomness (in v4) makes them resistant to enumeration attacks compared to sequential integers.

API Idempotency Keys: Clients can generate a UUID for each request and pass it as an idempotency key. If the same request is retried (e.g., due to a network timeout), the server recognizes the duplicate key and returns the original response instead of processing the operation again.

Auto-incrementing integers are simpler, smaller (typically 4–8 bytes vs. 16 bytes for a UUID), and naturally ordered. However, they require a centralized sequence generator (the database), expose business information through sequential values, and can cause contention in high-write distributed setups. UUIDs trade storage efficiency for decentralization and privacy.

ULID (Universally Unique Lexicographically Sortable Identifier) is a popular alternative that encodes a 48-bit millisecond timestamp followed by 80 bits of randomness, represented as a 26-character Crockford Base32 string. ULIDs sort lexicographically by creation time while being shorter to display than UUIDs. They solve the same index-locality problem as UUID v7 but predate its standardization.

Other alternatives include Twitter's Snowflake IDs (64-bit, composed of timestamp, worker ID, and sequence), which are compact and ordered but require centralized worker ID assignment. The right choice depends on your constraints: if you need zero-coordination generation with no external dependencies, UUIDs (especially v4 or v7) remain the most broadly supported option.

Always use a cryptographically secure random number generator (CSPRNG) for UUID v4 generation. Most standard library implementations (crypto.randomUUID() in JavaScript, uuid.uuid4() in Python, Uuid::v4() in Symfony) already handle this correctly.

If you're using UUIDs as database primary keys in PostgreSQL, use the native uuid data type rather than storing them as strings — it uses 16 bytes instead of 36 and supports efficient indexing. In MySQL 8+, use BINARY(16) or the built-in UUID_TO_BIN() function with the swap flag for better index performance.

Consider UUID v7 over v4 for new projects that use UUIDs as primary keys. The time-ordered prefix dramatically improves INSERT performance in B-tree indexes by reducing random page writes, while still maintaining the collision resistance you expect from UUIDs.

Password Generator — Generate cryptographically secure random passwords with configurable length and character sets.

Hash Generator — Compute MD5, SHA-1, SHA-256, and other hashes. Useful for understanding UUID v5's name-based hashing approach.