UUID, ULID, and Nano ID Generator
Generate UUID v4, UUID v7, ULIDs, and Nano IDs instantly. Compare sortable vs random formats and copy bulk IDs without leaving your browser.
IDs are generated client-side using crypto.getRandomValues(). Nothing is sent to a server. Use secure server-side generation in production where your architecture requires centralised control.
Click Generate to create IDs.
What is the difference between UUID v4 and UUID v7?
UUID v4 is fully random. Every bit (aside from the version and variant markers) is generated from a cryptographic random source. This makes it ideal for general-purpose uniqueness where ordering does not matter.
UUID v7 encodes a Unix millisecond timestamp in the first 48 bits and fills the remaining bits with random data. This means UUID v7 values are naturally sorted by creation time when compared lexicographically. For databases that use B-tree indexes (PostgreSQL, MySQL InnoDB), this improves insertion efficiency and reduces page splits compared to fully random UUID v4 values.
UUID v4 vs UUID v7 vs ULID vs Nano ID
| Feature | UUID v4 | UUID v7 | ULID | Nano ID |
|---|---|---|---|---|
| Sortable? | No | Yes (time-ordered) | Yes (lexicographic) | No |
| Length | 36 chars | 36 chars | 26 chars | Configurable (default 21) |
| Character set | Hex + hyphens | Hex + hyphens | Crockford Base32 | A-Za-z0-9_- (default) |
| Time-ordered? | No | Yes (ms precision) | Yes (ms precision) | No |
| URL-friendly? | Usable but long | Usable but long | Yes, compact | Yes, very compact |
| Best for | General-purpose uniqueness | Database keys, ordered events | Event logs, time-series keys | Public IDs, URLs, short codes |
| Common trade-off | Random → poor index locality | Newer standard, limited native support | Not an RFC standard | Collision risk if length is too short |
Use these IDs in your code
Copy-pasteable snippets for generating unique identifiers in popular languages.
JavaScript / Node.js
// UUID v4 (native)
crypto.randomUUID();
// Nano ID (npm: nanoid)
import { nanoid } from 'nanoid';
nanoid(); // default 21 chars
nanoid(10); // custom lengthPython
import uuid # UUID v4 str(uuid.uuid4()) # ULID (pip: python-ulid) from ulid import ULID str(ULID())
Go
import "github.com/google/uuid" // UUID v4 id := uuid.New().String() // UUID v7 id7, _ := uuid.NewV7() fmt.Println(id7.String())
Nano ID (JavaScript)
import { nanoid, customAlphabet } from 'nanoid';
// Default: 21 chars, URL-safe
const id = nanoid();
// Custom: 12 chars, lowercase + digits
const shortId = customAlphabet(
'abcdefghijklmnopqrstuvwxyz0123456789', 12
);
shortId();This tool runs entirely in your browser using the Web Crypto API. Generated IDs are never sent to CodeAva servers and are not stored between sessions. For production use, generate IDs server-side where your architecture requires centralised control.
Overview
Why applications need unique identifiers
Every system that creates records, events, or resources needs a strategy for assigning identifiers that are unique across time and space. The choice of ID format affects database performance, sort behaviour, collision probability, URL friendliness, and cross-service interoperability.
Developers today most commonly compare four formats: UUID v4 (random, universally supported), UUID v7 (time-ordered, newer RFC standard), ULID (lexicographically sortable, compact), and Nano ID (short, URL-friendly, configurable). Each format makes different trade-offs between randomness, sortability, length, and compatibility.
Sortable identifiers like UUID v7 and ULID are increasingly popular in database-heavy systems because they reduce B-tree page splits and improve insertion order efficiency. Random identifiers like UUID v4 and Nano ID remain the default where ordering is irrelevant and compactness or compatibility matters more.
Use cases
When to use it
- Database primary keysgenerate unique identifiers for rows in PostgreSQL, MySQL, MongoDB, or any datastore that needs distributed-safe primary keys.
- API resource IDscreate identifiers for API responses, webhooks, and inter-service references where predictability is undesirable.
- Event and log correlationgenerate sortable IDs for event streams, audit logs, and distributed tracing spans.
- URL-safe identifiersproduce short, URL-friendly IDs for public-facing slugs, invite links, and short codes.
- Distributed systemscreate globally unique identifiers without coordination between nodes or a central authority.
- Sorting by creation timeuse UUID v7 or ULID when insertion-order sorting matters without adding a separate timestamp column.
When it's not enough
- Cryptographic secretsUUIDs and ULIDs are identifiers, not secrets. Do not use them as authentication tokens, API keys, or passwords.
- Sequential auto-increment replacement without analysisswitching from auto-increment to random UUIDs can increase index size and reduce insertion performance. Evaluate UUID v7 or ULID if you need distributed uniqueness with better index locality.
- Short IDs for high-collision-tolerance systemsif you need very short IDs (under 10 characters), understand the collision probability at your expected volume. The shorter the ID, the higher the risk.
How to use it
- 1
Choose an ID format
Select UUID v4, UUID v7, ULID, or Nano ID from the format selector. Each option shows a description and characteristic badges.
- 2
Set quantity and options
Choose how many IDs to generate (1, 10, 50, or 100). Set case preference. For Nano ID, configure length and alphabet.
- 3
Generate instantly
Click Generate or wait for auto-generation. IDs appear immediately with type label, length, and characteristic badges.
- 4
Compare output characteristics
Review the badges (sortable, random, URL-friendly, time-ordered) to confirm the format fits your use case.
- 5
Copy the format you need
Copy a single ID or all IDs at once. Choose newline-separated, comma-separated, or JSON array export format.
Common errors and fixes
Choosing random IDs when sortable IDs would help
If your database performance depends on insertion order (B-tree indexes), consider UUID v7 or ULID instead of fully random UUID v4.
Assuming all UUID formats behave the same
UUID v4 is random with no time component. UUID v7 includes a timestamp prefix. They are the same length but have very different index and sorting behaviour.
Using long IDs where URL-friendly output is needed
UUID (36 chars) and ULID (26 chars) are fine for internal keys. For public-facing URLs or short links, Nano ID with a shorter length is often a better choice.
Not documenting ID format expectations across services
If one service generates ULIDs and another expects UUID format, parsing will fail silently. Document your ID strategy in your API contract.
Confusing lexicographic sort with strict chronological order
UUID v7 and ULID sort by creation time at millisecond granularity. IDs generated within the same millisecond may not preserve strict insertion order without additional monotonic counters.
Choosing a Nano ID length too short for the required collision tolerance
A 10-character Nano ID with the default alphabet has a meaningful collision probability at hundreds of millions of IDs. Use the Nano ID collision calculator to evaluate your volume requirements.