UUID / ULID Generator

UUID vs ULID vs NanoID: Which Should You Use in 2026?

Choosing the right unique identifier format has a real impact on database performance, URL readability, and system scalability. Each format was designed to solve a specific problem, and understanding the trade-offs helps you make the right call from the start.

UUID v4 is the universal standard. At 36 characters (32 hex + 4 hyphens), it is supported by every major database, framework, and programming language. RFC 9562 §5.4 lets an implementation either fill all 128 bits and overwrite the version and variant afterwards, or generate the exact required number of bits for random_a, random_b, and random_c (122 bits total). This page calls crypto.randomUUID() where the browser has it and otherwise fills sixteen bytes from crypto.getRandomValues() and sets those two fields by hand — both routes draw on the platform CSPRNG that RFC 9562 §6.9 asks for, and neither derives anything from Math.random(). Use UUID v4 when compatibility with existing tooling matters or when you are building an API that external consumers will work with.

UUID v7 — standardised in RFC 9562 in 2024 — is the time-ordered format to reach for today. Its layout is a 48-bit big-endian Unix timestamp in milliseconds, then the 4-bit version and 2-bit variant fields, then random data for the remainder. Because the timestamp sits in the most significant bits, v7 values sort by creation time under a plain byte-by-byte comparison — no MAC address, no node field of any kind. Implementations that need ordering to hold within a single millisecond may replace part of the random block with a monotonic counter, described in RFC 9562 §6.2. This page does not: it writes the 48-bit millisecond stamp and fills the remaining 74 bits from crypto.getRandomValues(), so two v7 values minted in the same millisecond sort in an arbitrary order relative to each other. Across milliseconds the ordering is exact.

UUID v1 is time-based but not time-sortable, and the difference matters. Its leading field is time_low — the low 32 bits of a 60-bit counter of 100-nanosecond intervals — so the first eight characters wrap roughly every 429.5 seconds and v1 values do not sort in creation order. RFC 9562 §2.1 makes the point directly: ordering v1 by time requires introspection, "as opposed to being able to perform a simple byte-by-byte comparison". Classic v1 also embeds the generating machine's MAC address in its node field, which lets anyone holding a UUID work out which host produced it. RFC 9562 §5.6 defines UUID v6 purely to reorder v1's fields for database locality, and §5.7 is explicit for new work: "Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible." This generator emits the v1 layout with a random, multicast-flagged node in place of a MAC address, so it leaks no hardware identity — but choose v7 when you actually want sortable IDs.

ULID (Universally Unique Lexicographically Sortable Identifier) uses 26 Crockford Base32 characters — time-sortable, URL-safe, case-insensitive. The first 10 characters encode 48-bit millisecond precision; the remaining 16 characters are 80-bit random. Like UUID v7, ULIDs sort naturally by creation time without a separate timestamp column, so a store whose write performance depends on keys arriving in order gets that property with no coordinating sequence. Note that ULID is not an IETF standard and carries no version or variant field: a ULID is not a UUID, and a column typed uuid will not take one.

UUID v5 is the odd one out here because it contains no randomness at all. RFC 9562 §5.5 defines it as the SHA-1 hash of a namespace UUID concatenated with a name, truncated to 128 bits, with the version and variant fields then overwritten — so the same namespace and the same name always yield the same UUID, on any machine, for ever. That is the point of it: a stable identifier for something that already has a natural key. The RFC also draws the boundary — where SHA-1 is unavailable or considered unsafe, a name-based UUID built on SHA-256 MUST NOT utilize UUIDv5 and MUST be within the UUIDv8 space. This page emits v5 only, using the browser's crypto.subtle.digest('SHA-1', …).

NanoID produces 21 URL-safe characters using a 64-character alphabet (A-Za-z0-9_-), achieving comparable collision resistance to UUID v4 with 41.7% fewer characters (21 against a UUID string's 36). The compact format is ideal for URL slugs, short-link systems, and API resource identifiers where brevity matters.

Why UUIDs Beat Auto-Increment IDs in Distributed Systems

Auto-increment integer IDs require a centralised counter — a single point of failure and a write bottleneck. In a single-database, single-server architecture this is fine, but as soon as you add a read replica, a second application server, or begin sharding your data, the centralised counter becomes a coordination problem. Every INSERT must contact the master database to obtain the next ID, creating latency and limiting write throughput.

UUIDs and ULIDs can be generated independently on any server, any microservice, or even in the browser itself — with zero coordination required. An order ID can be assigned by the client application before the record is written to any database. This is especially important for event-sourced systems, CQRS architectures, and multi-region deployments where network round trips are expensive.

The trade-off is database index locality. Random UUIDs (v4) scatter insertions across a B-tree instead of appending at its right edge: leaf pages fill, then split, and the index fragments — the page-fill-and-split behaviour PostgreSQL's fillfactor documentation describes for random insertion patterns. RFC 9562 §2.1 lists "poor database index locality" among the problems with random UUIDs and notes that the effects on B-tree indexes and their variants can be dramatic. The fix is a time-ordered identifier — UUID v7 or ULID — whose values append in time order, preserving the sequential-insert behaviour of auto-increment keys while keeping fully decentralised generation.

MySQL has no UUID column type at all — CREATE TABLE t (id UUID) is a syntax error. You pick the representation yourself: CHAR(36) or VARCHAR(36) to keep the readable hyphenated text, or BINARY(16) to store the 128 bits directly, converting with UUID_TO_BIN() and BIN_TO_UUID() (MySQL 8.0 and later). PostgreSQL does have a native uuid type, stored as 128 bits internally and declared simply as UUID in a CREATE TABLE statement.

How UUID v4 Randomness Actually Works

UUID v4 derives its 122 bits of randomness from the platform's cryptographically secure pseudorandom number generator. RFC 9562 §6.9 is the requirement: implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). In a browser that generator is reached through the Web Cryptography API, whose note on random-value generation says implementations should generate cryptographically strong random values using well-established cryptographic pseudo-random number generators seeded with high-quality entropy, such as from an operating-system entropy source. Math.random() carries no such requirement: ECMA-262 asks only for values chosen randomly or pseudo randomly with approximately uniform distribution over that range, using an implementation-defined algorithm or strategy, and promises nothing about unpredictability. A UUID built from it is not a v4 in any sense that matters.

The version (4) and variant (0b10) bits consume 6 of the 128 available bits, leaving 122 bits of effective randomness — 2¹²² ≈ 5.32 × 10³⁶ distinct values. Collision probability follows the birthday bound, P ≈ 1 − e^{−n² / (2 × 2¹²²)}, where n is the number of IDs generated. One billion IDs per second for one hundred years gives n ≈ 3.16 × 10¹⁸, which puts P at about 61% — so the even-odds point arrives a little earlier, at n ≈ 2.71 × 10¹⁸, or just over 86 years at that rate. Both figures describe a machine nobody is building; for any realistic application, UUID v4 collisions are not a practical concern.

The Crockford Base32 alphabet used in ULIDs was deliberately designed to eliminate visually ambiguous characters: no I (which looks like 1), no L (which looks like 1), no O (which looks like 0), and no U (which looks like V in some fonts). This makes ULIDs safer to read aloud, transcribe by hand, or display in error messages — a real ergonomic consideration for support teams and audit logs.