UUID Generator
Generate UUID v4, sortable UUID v7, or short Nano IDs in bulk.
Every value is generated locally using your browser’s cryptographic random number generator. UUID v7 embeds a millisecond timestamp, so a batch sorts in creation order — handy for database primary keys.
Generate random UUID v4 identifiers, time-sortable UUID v7 identifiers, or shorter URL-friendly Nano IDs, individually or in bulk — the identifiers used throughout databases, APIs, and distributed systems to uniquely name records without a central counter.
UUID v4 is fully random, while UUID v7 embeds a timestamp so IDs generated later naturally sort after earlier ones, which is friendlier to database indexes than pure random IDs.
Which identifier to use
| Type | Length | Sortable? | Good for |
|---|---|---|---|
| UUID v4 | 36 chars | No | General-purpose unique IDs |
| UUID v7 | 36 chars | Yes, by time | Database primary keys |
| Nano ID | 21 chars | No | Short links, public-facing IDs |
| Auto-increment | Short | Yes | Single-database systems only |
UUID v7 is usually the best default for a new table's primary key: globally unique like v4, but index-friendly like an auto-increment.
Why random primary keys hurt database performance
A B-tree index stores rows in key order. Insert sequential keys and every new row lands at the right-hand edge of the tree, touching one page that's already in memory. Insert random UUIDs and every insert lands in an arbitrary page, so the database must read that page from disk, split it, and write it back.
At scale the effect is substantial: page splits fragment the index, the working set no longer fits in cache, and insert throughput falls. This is exactly the problem UUID v7 solves — the leading bits are a millisecond timestamp, so inserts are broadly sequential while remaining globally unique.
Things worth knowing
- A UUID v4 has 122 random bits. Collisions are not a practical concern at any realistic scale.
- UUIDs are not secrets. They're unguessable enough to be awkward to enumerate, but they should never substitute for an authorisation check.
- Stored as text a UUID takes 36 bytes; stored in a native UUID or BINARY(16) column it takes 16. On a large table with several indexes, that difference is real.
- UUID v1 encodes the machine's MAC address and has been used to de-anonymise documents. Avoid it.
- A Nano ID at 21 characters has comparable collision resistance to a UUID v4 while being far more compact in a URL.
Frequently asked questions
- What's the difference between UUID v4 and v7?
- UUID v4 is entirely random. UUID v7 embeds a millisecond timestamp in its leading bits, so IDs generated later sort chronologically after earlier ones — better for database index performance.
- How likely is a UUID collision?
- For UUID v4, the chance of two randomly generated UUIDs colliding is astronomically small — you'd need to generate billions per second for centuries before a collision became likely.
- What is a Nano ID and when would I use one?
- Nano ID is a shorter, URL-safe random identifier — a good choice when you want something more compact than a UUID for things like short links or public-facing IDs.
- Are UUIDs safe to expose in a public URL?
- They're not secrets, but they are effectively unguessable, so exposing them doesn't leak record counts the way sequential IDs do. Always enforce authorisation server-side regardless.
- Should I store UUIDs as text or binary?
- Binary, where your database supports it — 16 bytes instead of 36, which matters for index size and cache efficiency on large tables. Postgres has a native uuid type; MySQL uses BINARY(16).
- Can a UUID v7 leak when a record was created?
- Yes — the timestamp is readable by anyone with the ID. That's usually harmless, but if creation time is sensitive, use v4 instead.