UUID Generator — v4, v7 and nil

Generate fresh UUIDs (v4 or v7) in your browser using the Web Crypto API. Pick a count, copy any single value or all of them at once. Nothing is sent to a server.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value formatted as 32 hexadecimal characters in five groups separated by hyphens (8-4-4-4-12). Two well-chosen UUIDs are extremely unlikely to collide, even when generated by separate machines without coordination — that property makes them ideal for primary keys, request IDs, file names and idempotency tokens.

UUID v4 is fully random and has been the default for years. UUID v7 (RFC 9562, 2024) embeds a millisecond Unix timestamp in the leading 48 bits, which makes the IDs sortable by creation time and far friendlier to database indexes. The nil UUID is an all-zero placeholder used to denote 'no value' in fields that require a UUID.

How to use this tool

Pick a UUID version: v4 for pure randomness, v7 for time-sortable IDs, nil for the all-zero sentinel.
Choose how many to generate at once (1 to 100). The list regenerates instantly any time you change a setting.
Click Copy next to one row to grab a single value, or Copy all to put the whole list (one UUID per line) in your clipboard.

Frequently asked questions

Are these UUIDs cryptographically secure?

Yes. We rely on the browser's crypto.randomUUID() (or crypto.getRandomValues() as a fallback), both of which expose the platform's CSPRNG. The random bits are suitable for unguessable session identifiers and secret tokens.

Should I use v4 or v7 in my database?

v7 is usually a better default. Because v7 IDs sort by creation time, B-tree indexes (the default in PostgreSQL, MySQL, SQL Server) stay packed and inserts hit the rightmost page. v4 fragments indexes and slows down inserts on large tables.

Can two generated UUIDs ever collide?

In theory yes; in practice, no. v4 has 122 random bits — generating one billion v4s per second for a hundred years still yields a collision probability under 1 in a billion. v7 mixes 74 random bits with a timestamp, so two collisions would require both the same millisecond and identical random suffix.

What does 'sortable' mean for v7?

Sort the IDs lexicographically (string sort) and you get them ordered by creation time. That property eliminates the need for a separate created_at column when you only need a coarse ordering, and makes time-bucketed queries efficient even without an index on a timestamp column.

Is the nil UUID safe to use?

It is a valid UUID and useful as a placeholder, but never use it for a real entity — many ORMs and frameworks treat it as 'absent'. If your database has a NOT NULL UUID column with a default, prefer DEFAULT gen_random_uuid() (Postgres) or a generated v7 over the nil value.

Common use cases

Where reaching for a UUID is the right call.

Database primary keys

Avoid sequential integer IDs that leak business volume in URLs and let attackers iterate. UUIDs are unguessable, can be generated client-side without round-tripping the database, and merge cleanly across distributed systems.

Idempotency keys for API requests

Generate one UUID per logical user action and pass it as an Idempotency-Key header. The server can then de-duplicate retries safely — exactly the pattern Stripe and other payment APIs use.

Correlation IDs in distributed logs

Attach the same UUID to every log line, span and downstream request a single user action produces. Searching for that ID in your aggregator pulls the entire trace across services.

Unique filenames

Naming uploaded files <uuid>.<ext> sidesteps name collisions, removes the need to sanitize user input, and prevents path-traversal attacks via crafted file names.

Tips and shortcuts

Habits that make UUIDs easier to live with.

Prefer v7 for new schemas

Unless you have a specific reason to want fully unsorted IDs (security through obscurity in URLs, for example), v7 is faster on disk, easier to debug — you can read the timestamp — and just as collision-resistant as v4.

Store as native UUID, not as a string

PostgreSQL, MySQL 8 and SQL Server have native UUID/UNIQUEIDENTIFIER types that store 16 bytes instead of 36. The space saving matters at scale and the comparison is faster.

Don't expose v1 or v2 publicly

v1 leaks the MAC address of the generating machine. v2 (DCE Security) leaks POSIX UID. Both are obsolete; use v4 or v7 instead.

Trim the dashes if you must shorten

Removing the four hyphens cuts the string from 36 to 32 characters and is reversible. Avoid Base64-encoding the bytes — the result is shorter (22 chars) but no longer recognizable as a UUID and breaks tooling expecting the canonical format.