UUID / ULID Generator

API DEVELOPER RANDOM ULID UUID

By AI Tools Desk

About this tool

Generate UUIDs v1/v4 and ULIDs instantly — bulk generation, multiple formats.

Generate UUID v4, v7, v5 and v1, plus ULIDs and NanoIDs instantly. Bulk generation up to 100 IDs, uppercase, no-hyphens, quote wrapping. Free, 100% client-side.

RT-DEV-007 · Developer Tools

Quantity 1 – 100

Format options

Uppercase No hyphens Wrap in quotes Wrap in braces

Generated locally using crypto.getRandomValues(). Nothing is sent to any server.

How to Use the UUID / ULID Generator

Choose your ID format

Select UUID v4 for most applications, UUID v7 or ULID when you need IDs that sort by creation time, UUID v5 for deterministic namespace-based IDs, or NanoID for compact URLs and short references.

Set the quantity

Generate 1 to 100 IDs at once for bulk database seeding, test data generation, or API payload construction. The generator runs instantly regardless of count.

Apply format options

Enable uppercase, remove hyphens, or wrap each ID in quotes or braces for direct use in SQL INSERT statements, JSON arrays, or CSV seed files.

Copy or download

Hover over any line and click its Copy button to grab a single ID. Use Copy All to send the full list to your clipboard, or Download .txt to save it as a file for import into your database tooling.

UUIDs, ULIDs and Unique Identifiers in Modern Software

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. UUID v4 packs 122 bits of cryptographic randomness — collision probability is so low it is functionally impossible. 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.

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, which is why they are a common choice for event-sourced systems and for distributed stores such as Apache Cassandra and Amazon DynamoDB.

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.

"Generate one billion UUID v4s every second for 100 years and you reach roughly 3.16 × 10¹⁸ of them — about a 61% chance that two are identical. The 50/50 point arrives earlier, at 2.71 × 10¹⁸ UUIDs, or just over 86 years at that rate."

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 your operating system's Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). In browsers, this is accessed via crypto.getRandomValues() — which feeds from hardware entropy sources including thermal noise, interrupt timing, and hardware random number generators present in modern CPUs. This is fundamentally different from Math.random(), which uses a deterministic algorithm (typically xorshift128+) that can be predicted if an attacker observes enough outputs.

The version (4) and variant (RFC 4122) 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.

Collision odds, version bits, and what the RFCs changed

A UUID v4 contains 122 bits of randomness — the remaining 6 bits specify the version (4) and variant (RFC 4122).

The probability of generating two identical UUID v4s is approximately 1 in 5.3×10³⁶ — for all practical purposes, UUID collisions are impossible.

UUID stands for Universally Unique Identifier — first standardised in RFC 4122 in 2005, and re-standardised in RFC 9562 in 2024, which added versions 6, 7 and 8.

ULID stores the timestamp in the first 10 characters — making ULIDs naturally sortable by creation time without a separate timestamp column.

MySQL has no UUID column type — you choose the representation yourself: CHAR(36)/VARCHAR(36) text, or BINARY(16) via UUID_TO_BIN() and BIN_TO_UUID().

Classic UUID v1 embeds the generating machine's MAC address in its node field, so a v1 value can reveal which host produced it. RFC 9562 §5.7 says to prefer v7.

NanoID reaches collision resistance comparable to UUID v4 in only 21 characters — 41.7% fewer than a UUID string's 36.

Crockford Base32 excludes visually ambiguous characters: no I, L, O, or U — eliminating confusion when IDs are read aloud or transcribed manually.

Two UUIDs are reserved as sentinels: the Nil UUID (all 128 bits zero, 00000000-0000-0000-0000-000000000000) and the Max UUID (all bits one, ffffffff-ffff-ffff-ffff-ffffffffffff) — the Max form was only formally defined in RFC 9562 §5.10 in 2024.

The format predates its IETF standard by about two decades: UUIDs came out of Apollo Computer's Network Computing System in the 1980s, were carried into the Open Software Foundation's DCE, and shipped in Windows as the GUID long before RFC 4122 formalised them in 2005.

Frequently Asked Questions

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify information in computer systems. UUIDs are used as primary keys in databases, resource identifiers in APIs, session tokens, transaction IDs, and anywhere a unique identifier needs to be generated without central coordination. UUID v4 is the most common form — it uses 122 bits of cryptographic randomness to ensure uniqueness across all systems without any coordination between generators.
UUID v1 is time-based — it embeds a 60-bit timestamp plus the generating machine's MAC address — but it is not time-sortable. Its leading field is time_low, the low 32 bits of the timestamp, which wraps roughly every 429.5 seconds, so sorting v1 values as strings or bytes does not give creation order. RFC 9562 §2.1 puts it in terms of needing introspection "as opposed to being able to perform a simple byte-by-byte comparison". The embedded MAC address also exposes which host generated each UUID. UUID v4 is pure cryptographic randomness with no timestamp or machine information, making it privacy-safe but equally unsortable. For new applications RFC 9562 §5.7 recommends UUID v7 — a 48-bit Unix millisecond timestamp in the most significant bits, so it genuinely sorts by creation time — or ULID.
A ULID (Universally Unique Lexicographically Sortable Identifier) is a 26-character Crockford Base32 string that encodes a 48-bit millisecond timestamp in the first 10 characters and 80-bit random data in the remaining 16. Use ULID when you need IDs that sort chronologically — especially in distributed databases (Cassandra, DynamoDB) where time-ordered writes improve query performance and reduce hotspots. ULIDs are also URL-safe and case-insensitive, making them more ergonomic than hyphenated UUIDs.
Theoretically yes, but the probability is astronomically low. UUID v4 has 122 bits of randomness — the collision probability formula gives approximately 50% chance of collision only after generating 2.71 × 10¹⁸ UUIDs. At one billion UUIDs per second, that would take just over 86 years. No real application will ever generate enough UUIDs to make collision a practical concern. For truly collision-critical systems, you can add a unique database constraint as a safety net, but it will never trigger in practice.
NanoID is a 21-character URL-safe random identifier using a 64-character alphabet (A-Za-z0-9_-). It achieves collision resistance comparable to UUID v4 but uses 41.7% fewer characters — 21 against a UUID string's 36 — making it ideal for URLs, API slugs, and short-link systems where compactness matters. Unlike UUID v4, NanoID has no hyphens, no fixed version/variant bits, and is safe to use directly in URLs without encoding. The trade-off is that NanoID is not an established standard — some systems require UUID format specifically.
MySQL has no UUID column type, so the choice is yours. The compact option is BINARY(16) — the raw 128 bits — rather than the 36-character CHAR(36)/VARCHAR(36) text form. Convert with MySQL's built-in UUID_TO_BIN() on the way in and BIN_TO_UUID() on the way out (both MySQL 8.0 and later). The optional second argument, UUID_TO_BIN(uuid, 1), swaps the time-low and time-high fields to improve index locality for v1 UUIDs; MySQL's manual notes that this swapping provides no benefit for values that are not time-based v1 UUIDs, so leave it off for v4 and v7.
Yes. crypto.randomUUID() is a Web Crypto API method available in all modern browsers and Node.js 15.6+. It generates a compliant RFC 4122 UUID v4 using the operating system's cryptographically secure random number generator — the same entropy source used for TLS, key generation, and other security-critical operations. This generator uses crypto.randomUUID() when available and falls back to a manual crypto.getRandomValues() implementation for older browsers.
Crockford Base32 was chosen for ULIDs because it is URL-safe, case-insensitive, and deliberately excludes visually ambiguous characters. The standard Base32 alphabet includes I (looks like 1), L (looks like 1), O (looks like 0), and U (looks like V) — Crockford removes all four. This makes ULIDs safer to display in error messages, logs, and user interfaces, and easier to transcribe correctly over the phone or in support tickets — an ergonomic advantage over hex-based formats.
Most languages have built-in UUID support. In PHP: Str::uuid() (Laravel) or ramsey/uuid library. In Python: import uuid; uuid.uuid4(). In JavaScript/Node.js: crypto.randomUUID() (built-in since Node 15.6) or the uuid npm package. In Go: github.com/google/uuid. In Java: UUID.randomUUID() (built-in). In PostgreSQL: gen_random_uuid() (built-in since v13) or uuid_generate_v4() from the uuid-ossp extension.
PostgreSQL 13 and later ships gen_random_uuid() in core — it generates a UUID v4 and needs no extension. Before 13 the same function came from the pgcrypto extension, and the uuid-ossp extension's uuid_generate_v4() was the other common route. PostgreSQL stores UUIDs in a native 128-bit type declared simply as UUID in CREATE TABLE — unlike MySQL, which has no UUID type and leaves the representation to you.

Related News

You may be interested in these recent stories from our newsroom.

View all news →

UUID / ULID Generator