UUID Generator — v4, v1, ULID, NanoID

A UUID (Universally Unique Identifier, also called GUID on Windows) is a 128-bit identifier defined in RFC 4122. It is designed to be unique across all systems without coordination — any computer can generate one and be statistically certain it has never been generated before. Use UUIDs for database primary keys (to avoid sequential ID enumeration), session tokens, file upload identifiers, job queue IDs, distributed system event IDs, and any context where uniqueness must be guaranteed across multiple systems or time periods.

UUID v4 is fully random (122 random bits) — two consecutive v4 UUIDs look completely unrelated and cannot be sorted chronologically. UUID v1 encodes the current timestamp (60-bit, 100-nanosecond precision) plus a clock sequence and node identifier. This makes v1 UUIDs roughly sortable by creation time. Use v4 when you need maximum randomness and privacy; use v1 (or its privacy-preserving alternative, ULID) when you need time-ordered IDs for database clustering performance.

In theory, yes — in practice, essentially never. UUID v4 has 2¹²² possible values (approximately 5.3 × 10³⁶). Generating 1 billion UUIDs per second for 100 years would yield roughly 3.15 × 10¹⁸ UUIDs — the probability of any collision in that set is approximately 1 in 10¹⁸. For virtually all applications, UUID v4 collision probability is so low it can be treated as impossible. If you need guaranteed uniqueness in a distributed system, use a database sequence or a coordination service alongside UUIDs.

NanoID is a compact random identifier library that generates URL-safe IDs using a 64-character alphabet. At 21 characters, a NanoID has the same collision probability as UUID v4 but is 36% shorter and contains no hyphens. Use NanoID instead of UUID when: the ID will appear in URLs (shorter is better), hyphens would cause parsing issues (CSS class names, HTML ids, filenames on some systems), or you need human-readable IDs that are easier to select and copy from UI elements.

PostgreSQL has a native UUID type that stores UUIDs as 16-byte binary internally while accepting and displaying them as standard 36-character strings — use the UUID type. MySQL has no native UUID type; store as CHAR(36) for human-readable format or BINARY(16) for performance (use UNHEX(REPLACE(uuid(),'-','')) to store). SQLite stores UUIDs as TEXT. For high-performance primary keys in MySQL/MariaDB, consider UUID v7 (not yet widely implemented) or ULID, which sort naturally and cause less index fragmentation than random UUIDs.

Yes — UUID v4 uses crypto.randomUUID(), a browser API backed by the operating system's cryptographically secure pseudorandom number generator (CSPRNG). NanoID uses crypto.getRandomValues() with rejection sampling to avoid modulo bias. Both produce UUIDs that are suitable for security-sensitive use cases. These are not Math.random()-based generators — they use the same entropy source as SSL/TLS key generation.