UUID Generator (v4 and v7)

What a UUID is, and why 1, 2, 3 stops working

A UUID is a 128-bit identifier written as 32 hexadecimal digits in five hyphen-separated groups, 8-4-4-4-12, for example 550e8400-e29b-41d4-a716-446655440000. The point of the format is that any machine can mint one on its own, with no coordination and no round trip to a central allocator, and still be confident nobody else produced the same value. This page builds them with crypto.randomUUID() and crypto.getRandomValues(), the browser APIs intended for cryptographic use.

The obvious alternative, an auto-incrementing integer, needs a single writer handing out numbers, so an offline client or a second region cannot create a row and reconcile later, and merging two databases that both started at 1 turns into a re-keying project. The values are also public arithmetic: a customer who sees /invoices/1042 learns roughly how many invoices you have issued and can try 1041.

Six of the 128 bits are spoken for: four mark the version and two the variant, which is why every v4 here has a 4 at the start of the third group and an 8, 9, a or b at the start of the fourth. That leaves 122 random bits, and by the birthday bound you would need on the order of 2^61 values before a repeat became likely. RFC 4122 defined the format in 2005; RFC 9562 replaced it in May 2024 and made v6, v7 and v8 official.

Which version to generate

This page generates the two versions worth choosing between for new work. The rest are here so you recognize them in someone else’s data.

• v4, random: 122 bits of randomness and nothing else. No ordering, no embedded metadata, the widest support. Pick it for public-facing identifiers and anywhere the creation time should stay private.
• v7, time-ordered: a 48-bit Unix millisecond timestamp followed by randomness, so later values sort after earlier ones as text and as raw bytes. The better default for database primary keys and event ids.
• v1, time and MAC address: the original layout. It embeds the network card of the generating machine and does not sort by time. Worth recognizing because UUID() in MySQL returns one.
• v3 and v5, name-based: a hash of a namespace plus a name, MD5 for v3 and SHA-1 for v5. The same input always gives the same UUID, which is how you derive a stable identifier from a URL. Not random, so never where unguessability matters.
• v6, v8, Nil and Max: v6 is v1 reordered so it sorts, v8 is an empty slot a vendor fills itself, and the all-zero Nil and all-f Max are reserved sentinels, not identifiers to hand out.

How to generate a batch for seed data or a migration

1. Choose the version. If the identifiers go into a table you will query in creation order, pick v7; otherwise v4 is fine.
2. Set How many to the number of rows you need. The field takes 1 to 1000 and the list regenerates as the value changes.
3. Press Regenerate for a fresh set with the same settings. Nothing is remembered, so a reload gives different values.
4. Press Copy all. The identifiers arrive one per line, which is what a spreadsheet column, a SQL VALUES list and most CSV importers expect. The button on a row copies just that one.
5. Paste them somewhere durable before you close the tab, because nothing here is stored.

For test fixtures, committing literal values beats calling a generator at test time: a failing test then points at a constant you can search for.

How to use v7 as a primary key without regrets

1. Declare the column with the 16-byte native type where one exists: uuid in PostgreSQL, uniqueidentifier in SQL Server, BINARY(16) in MySQL, a BLOB or TEXT column in SQLite.
2. Generate the value in the application unless your database has a v7 function. Knowing the id before the insert lets you build a whole object graph in memory and write it in one transaction.
3. Keep it out of public URLs if the creation time is sensitive. A v7 announces when a row was made, and a run of them announces how fast rows are being made.
4. Give people a separate short reference, such as an invoice number. Nobody wants to dictate 36 characters over the phone.
5. Index deliberately. Every secondary index carries a copy of the 16-byte key, so six indexes pay that cost six times.

Getting the identifiers where you need them

There is no download button here on purpose: a list of UUIDs is small enough that the clipboard beats a file. Copy all joins them with newlines, so where they land decides what you get.

• Spreadsheets: a newline-separated paste fills one cell per row in Excel, Numbers or Google Sheets.
• Code and SQL: paste into your editor and use multi-cursor editing to wrap each line in quotes and commas. Editors based on VS Code drop a cursor on every line with Ctrl+Alt+Down or Cmd+Option+Down.
• Terminals: Ctrl+Shift+V on most Linux terminals, Cmd+V on macOS, Ctrl+V or right click in Windows Terminal. A multi-line paste can run immediately in a shell, so go through an editor if you are unsure what you copied.
• iPhone and Android: press and hold in the field and tap Paste. iOS asks permission the first time one app reads what another copied; on Android, Gboard keeps a clipboard history behind the icon on its toolbar.

Generating and storing UUIDs in each stack

Every ecosystem has a built-in v4; support for v7 is newer and uneven. These notes describe the situation at the time of writing, so check what your own versions ship.

• JavaScript and TypeScript: crypto.randomUUID() returns a v4 in browsers and in Node, but needs a secure context, so it is undefined on a plain HTTP page. There is no built-in v7; take it from a library such as uuid, or build it on crypto.getRandomValues() as this page does.
• PostgreSQL: a native uuid type stored as 16 bytes, with gen_random_uuid() built in since version 13 for a v4. Recent versions add uuidv4() and uuidv7(); if yours lacks them, generate v7 in the application.
• MySQL and MariaDB: no UUID column type, and UUID() returns a v1 that does not sort by time. The usual pattern is UUID_TO_BIN(uuid, 1) into a BINARY(16) column, where the second argument swaps the time fields so the stored bytes sort, with BIN_TO_UUID(id, 1) on the way out. Use the same flag on both sides or you get scrambled values.
• SQLite and SQL Server: SQLite has neither a UUID type nor a generator, so store text or a 16-byte BLOB and generate in the application. SQL Server has uniqueidentifier, with NEWID() for a random value and NEWSEQUENTIALID() for one that increases within a session.
• Python, Java and Go: uuid.uuid4() and UUID.randomUUID() ship in the standard library, and Go usually reaches for github.com/google/uuid, which also has v7. Time-ordered versions reached the Python uuid module only recently and the JDK class has no v7 factory, so check your version.
• .NET: Guid.NewGuid() is a v4 and recent versions add a v7 factory. Watch the byte order: Guid.ToByteArray() writes the first three fields little-endian, so sharing a BINARY(16) column with another language silently produces identifiers that no longer match.

Comparison is the other trap. UUIDs compare case-insensitively as UUIDs but not as strings, so normalize to lowercase with hyphens on the way in and decide once whether your API returns the hyphenated form or the bare 32 characters.

Limits, privacy and honest caveats

What leaves your browser: nothing. Every identifier here is produced locally by crypto.randomUUID() or crypto.getRandomValues(), and none is transmitted, logged or stored. None can be recovered either, so copy what you need before the tab closes.

A UUID is an identifier, not a credential. The 122 random bits in a v4 are genuinely hard to guess, but the value is designed to be shared, and code that treats knowledge of an id as proof of access is one leaked log line from a breach. A v7 is weaker still in that respect, because the first half is a timestamp anyone can read. Authorize on the server and use purpose-built secrets for tokens.

Time-ordering has a privacy cost. Publishing v7 identifiers publishes your creation timestamps, and a handful of them reveals your rate of activity. If that matters, keep the v7 as an internal key and expose a v4 or an opaque slug.

Uniqueness depends on good randomness. The collision argument assumes a cryptographic random source. It holds here and in the standard library functions above, but not for anything built on Math.random().

They are hard on people. Thirty-six characters with no redundancy cannot be read aloud or typed reliably from a printout, and screen readers announce them one character at a time. Where a human handles the reference, pair the UUID with a short human code.