UUID / ULID Generator

API DEVELOPER RANDOM ULID UUID

About this tool

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

Generate UUIDs v4/v1, ULIDs and NanoIDs instantly. Bulk generation up to 100 IDs, uppercase, no-hyphens, quote wrapping. Free, no signup, 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, ULID for sortable IDs where database index performance matters, 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 v1 was the original time-ordered UUID, embedding the generating machine's MAC address as the node field. This created a privacy problem: forensic analysis of UUID v1 values could identify which server (and approximately when) generated a specific record. UUID v1 is now mostly deprecated for external use. UUID v7 — standardised in RFC 9562 in 2024 — solves this by using a monotonic random counter for the node field while retaining time-ordering. This generator produces a v1-style time-ordered UUID without embedding any MAC address, making it privacy-safe.

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. ULIDs sort naturally by creation time without a separate timestamp column, making them excellent for distributed databases like Apache Cassandra or Amazon DynamoDB where time-ordered writes dramatically reduce write hotspots. GovTech Singapore's systems use UUID-class identifiers for SingPass transaction IDs, and fintech platforms across ASEAN are increasingly adopting ULIDs for event-sourced architectures.

NanoID produces 21 URL-safe characters using a 64-character alphabet (A-Za-z0-9_-), achieving the same collision resistance as UUID v4 with 31% fewer characters. The compact format is ideal for URL slugs, short-link systems, and API resource identifiers where brevity matters. GitHub uses a similar approach for shortened URLs and gist IDs.

"The probability of a UUID v4 collision is so low that if you generated 1 billion UUIDs every second for 100 years, you'd have less than a 50% chance of a duplicate."

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 performance. Random UUIDs (v4) cause B-tree fragmentation because each new insertion lands at a random position in the index rather than appending to the end. This increases write amplification and can slow bulk inserts significantly. The solution is to use time-ordered identifiers: ULID or UUID v7. Both append to the end of B-tree indexes in time order, preserving the sequential-insert performance advantage of auto-increment IDs while retaining full decentralised generation.

MySQL stores UUIDs as VARCHAR(36) by default — storing as BINARY(16) instead saves approximately 60% of storage per column and significantly improves index performance. PostgreSQL has a native UUID type that stores as 128-bit binary internally, giving it better default performance than MySQL's VARCHAR approach.

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) consume 6 of the 128 available bits, leaving 122 bits of effective randomness. The collision probability formula is P ≈ n² / (2 × 2¹²²) where n is the number of IDs generated. Generating one billion IDs per second continuously for one hundred years produces approximately n = 3.15 × 10¹⁸ IDs — and P remains below 50%. 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 — an important ergonomic consideration for support teams and audit logs across ASEAN markets where manual transcription remains common in enterprise workflows.

10 Facts About UUIDs and Unique Identifiers

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, though they were in use since the 1980s in Apollo NCS and Microsoft COM.

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

GitHub uses an internal system similar to NanoID for shortened URLs and gist IDs — preferring compact URL-safe strings over full UUIDs.

MySQL stores UUIDs as VARCHAR(36) by default — but storing as BINARY(16) saves 60% space and improves index performance significantly.

UUID v1 was deprecated for public APIs after researchers showed that MAC addresses (embedded in v1 UUIDs) could identify which server generated a particular UUID.

The NanoID library achieves the same collision probability as UUID v4 using only 21 characters — 31% fewer than a UUID.

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

In distributed databases like Apache Cassandra (used by major ASEAN e-commerce platforms), time-ordered IDs like ULIDs significantly reduce write hotspots compared to random UUIDs.

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 the current timestamp and the generating machine's MAC address, making UUIDs from the same machine sortable by creation time. However, embedding the MAC address exposed which server generated each UUID, raising privacy and security concerns. UUID v4 uses pure cryptographic randomness with no timestamp or machine information embedded, making it privacy-safe but not inherently sortable. For new applications, UUID v7 (time-ordered, privacy-safe) or ULID are better alternatives to v1.
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 over 85 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 the same collision probability as UUID v4 but uses 31% fewer characters — 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.
Store UUIDs as BINARY(16) rather than VARCHAR(36). Use MySQL's built-in UUID_TO_BIN(uuid, 1) function (the second argument swaps the time-high and time-low bytes for better index locality with v1 UUIDs) and BIN_TO_UUID() for retrieval. This saves 20 bytes per row and dramatically improves index performance because the binary representation is more compact and comparisons are faster. For UUID v4, the swap argument is optional but harmless.
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 includes the built-in function gen_random_uuid() which generates UUID v4 using the pgcrypto extension's random source. Older versions required the uuid-ossp extension's uuid_generate_v4(). PostgreSQL stores UUIDs in a native 128-bit binary type (not VARCHAR), giving excellent index and storage performance compared to MySQL's default VARCHAR(36) approach. The column type is declared as simply UUID in CREATE TABLE statements.

UUID / ULID Generator