UUID Generator
Bulk UUID v4 and v7, plus short IDs and ULID-style keys.
What a UUID is
A UUID (universally unique identifier), also called a GUID, is a 128-bit value written as 36 characters: 3f2a9c14-7d3e-4b6f-91ad-0e5c2b8f7a41. The point is that any machine can mint one at any time, without coordinating with a database or a central service, and still be safe from collisions. That makes it the natural primary key for distributed systems, offline-capable clients and anything that has to generate IDs before it can talk to a server.
v4 or v7?
UUID v4 is 122 random bits. It is what most people mean by “UUID”, it leaks no information, and it is the right default when identifiers are exposed publicly. Its weakness is database performance: random values scatter inserts across a B-tree index, which fragments pages and slows writes on large tables.
UUID v7, standardised in RFC 9562 in 2024, fixes exactly that. The first 48 bits are a Unix millisecond timestamp and the rest is random, so IDs generated later sort after IDs generated earlier. Inserts land at the end of the index, and you can sort by primary key to get creation order for free. Use v7 for new database keys; use v4 when the ID is public and the creation time must stay private.
ULID reaches the same goal with a different encoding: 26 Crockford base32 characters, shorter than a UUID, case-insensitive and free of ambiguous letters. NanoID is smaller still — 21 URL-safe characters with collision odds comparable to a v4 UUID — and is a good fit for short links and public slugs.
How to use it
- Pick a type, set how many you need, and press Generate.
- Adjust casing and hyphens to match your target system — SQL Server tends to want braces, Postgres does not.
- Choose an output format to paste straight into a seed file, a test fixture or a migration.
- Copy them all, or download as a text file.
Frequently asked questions
Are these actually random?
Yes. Every value comes from crypto.getRandomValues(), the browser's cryptographically secure random number generator — the same source used for TLS key material. This is not Math.random(), which is predictable and unsuitable for identifiers.
Could two of these ever collide?
Not in practice. A v4 UUID has 122 random bits. You would need to generate roughly 2.7 × 1018 of them before reaching a one-in-a-billion chance of a single collision — about a billion per second for 85 years. Hardware failure is a far likelier source of duplicate keys.
Does a UUID v7 leak when a record was created?
Yes, to the millisecond, and that is intentional. If your identifiers appear in public URLs and creation time is sensitive — signup order, a queue position — use v4 instead.
Should I store UUIDs as text or binary?
Use a native type where one exists: uuid in PostgreSQL, uniqueidentifier in SQL Server. Both store 16 bytes. In MySQL use BINARY(16) rather than CHAR(36) — it more than halves the storage and the index size.
Is anything sent to a server?
No. Generation happens entirely in your browser, so the identifiers exist only on your machine until you paste them somewhere. Server-side generators, by contrast, know every ID they have ever handed out.