UUID / GUID generator

How to use this tool#

1. Pick a version. v4 is random and is what most systems mean by "a UUID". v7 puts a timestamp at the front so the values sort by the order they were made.
2. Set how many you need, from 1 to 1000. They are generated in one batch.
3. Choose the format. Uppercase, hyphens on or off, and braces for the {...} GUID style. Changing these reformats what is already on screen.
4. Press Generate, then copy. The button above the output copies the whole batch. Batches of 50 or fewer also get a copy button on every line.
5. Paste anything into "Inspect a UUID" to see whether it is valid and read back its version, its variant and, for the time-based versions, when it was created.

One v4 UUID is generated as soon as the page loads, so if you only need one, it is already waiting for you.

What is a UUID?#

A UUID (Universally Unique Identifier) is a 128-bit identifier that any machine can create on its own, without coordinating with a central authority, and still be unique for all practical purposes. It is written as 32 hexadecimal digits in five hyphen-separated groups of 8-4-4-4-12 characters.

The current specification is RFC 9562, published in May 2024, which obsoletes the older RFC 4122. It defines versions 1 to 8 plus two special values, the Nil UUID and the Max UUID.

How to read a UUID#

Two digits in the string are not random. The first digit of the third group is the version, and the first digit of the fourth group carries the variant:

9c5b94b1-35ad-49bb-b118-8e8fc24abf80
              ^    ^
              |    +-- variant: 8, 9, a or b means RFC 9562
              +------- version: 4 (random)

The variant is the two most significant bits of the ninth octet. RFC 9562 fixes them to 10, which is why that digit reads 8, 9, a or b on any modern UUID. The other ranges are reserved: 0-7 for the old Apollo NCS layout, c-d for Microsoft backward compatibility, and e-f for future use. The rest of the 128 bits means whatever the version says it means.

v4 or v7: which one should you use?#

v4 is random. 122 of its 128 bits come straight from a random source; the other 6 are the version and variant. It says nothing about when or where it was made, which is exactly what you want for an identifier you hand out. It is the default in nearly every library, and it is what people mean when they say "generate a UUID".

v7 is time-ordered. RFC 9562 lays its 128 bits out like this:

• unix_ts_ms, 48 bits: milliseconds since the Unix epoch, big-endian.
• ver, 4 bits: 0111.
• rand_a, 12 bits: random, or a counter that keeps UUIDs made within the same millisecond in order. This page uses it as a counter.
• var, 2 bits: 10.
• rand_b, 62 bits: random, and optionally more counter.

Because the timestamp sits at the front and UUIDs sort as raw bytes, v7 values come out in creation order. RFC 9562 gives the practical reason in section 6.11: "Time-ordered monotonic UUIDs benefit from greater database-index locality because the new values are near each other in the index", and the difference against random inserts "can be one order of magnitude or more".

In a B-tree index, each new v4 key lands in a different place in the tree, so the database keeps pulling cold pages into memory and splitting pages all over the index. v7 keys arrive next to each other, so the part of the index being written stays small and stays in cache.

• Use v7 for primary keys and anything inserted in volume and indexed, especially where you would otherwise reach for an auto-incrementing integer.
• Use v4 when the value is public, or when the creation time should not be readable. A v7 UUID tells anyone who sees it, to the millisecond, when the row was created.

UUID and GUID: the same thing#

GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit identifier. The first sentence of RFC 9562 says so outright: UUIDs are "also known as GUIDs". Anything that accepts a UUID accepts a GUID.

Two differences are worth knowing. First, formatting: Microsoft tooling often prints the value wrapped in curly braces, like {9c5b94b1-35ad-49bb-b118-8e8fc24abf80}, and RFC 9562 notes that some implementations output UUIDs that way. Turn on the Braces option above to match it. Second, byte order: .NET's Guid.ToByteArray() writes the first three fields little-endian, so the bytes are not in the same order as the text. The text form is identical either way, but a raw 16-byte GUID from .NET is not a raw 16-byte UUID.

The Nil and Max UUIDs#

Two values are reserved and carry no version. The Nil UUID has all 128 bits set to zero (RFC 9562 section 5.9). It is the standard placeholder for "no UUID" in a field that cannot be null, and it is what people are usually after when they search for an empty GUID.

00000000-0000-0000-0000-000000000000

The Max UUID is its inverse, all 128 bits set to one (section 5.10). It is useful as an upper bound when scanning a range of UUIDs.

ffffffff-ffff-ffff-ffff-ffffffffffff

Neither falls inside the RFC 9562 variant, so the inspector above reports them as special values rather than as a version. The generator does not produce them, since they are constants rather than something to generate: copy them from here instead.

How unique is a v4 UUID?#

A v4 UUID has 122 random bits, so there are 2¹²² of them: about 5.3 × 10³⁶ values.

The useful question is not how many exist but how many you can draw before two come out the same, which is the birthday problem. Draw 103 trillion (1.03 × 10¹⁴) v4 UUIDs and the chance that any two of them match is around one in a billion. At a billion UUIDs the chance is roughly one in 10¹⁹. For any system you are likely to build, a collision is not the risk worth planning for.

That arithmetic assumes the random source is actually random. This is where v4 really fails in practice: a UUID built from Math.random() or a badly seeded generator can repeat far sooner than the maths suggests. This page uses the browser's Web Crypto API, crypto.randomUUID() where it exists and crypto.getRandomValues() otherwise, which is a cryptographically secure source.

Nothing here leaves your browser#

The UUIDs are generated on your machine, by your browser, after the page has loaded. They are not sent anywhere and there is nowhere to send them: this site is static files, with no backend and no logging of what the tool produces. Disconnect from the network and the generator keeps working.

Separately, and more importantly: a UUID is not a secret. RFC 9562 section 8 is blunt about it. "Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access)." If you need a token, generate a token.

Generating a UUID in code#

JavaScript

// v4. Browsers need a secure context; Node has the global from v19.
const id = crypto.randomUUID();
// '9c5b94b1-35ad-49bb-b118-8e8fc24abf80'

// v7. Node 26.1+ only. No browser API for it yet.
const ordered = crypto.randomUUIDv7();

Python

import uuid

uuid.uuid4()        # UUID('9c5b94b1-35ad-49bb-b118-8e8fc24abf80')
str(uuid.uuid4())   # '9c5b94b1-35ad-49bb-b118-8e8fc24abf80'

uuid.uuid7()        # time-ordered, Python 3.14+

Go

import "uuid" // standard library, Go 1.27+

id := uuid.New()          // v4, same as uuid.NewV4()
ordered := uuid.NewV7()   // time-ordered

// Before Go 1.27, github.com/google/uuid does the same job:
// uuid.New() panics on failure, uuid.NewV7() returns (UUID, error).

PostgreSQL

SELECT gen_random_uuid();  -- v4, in core since PostgreSQL 13
SELECT uuidv7();           -- v7, PostgreSQL 18+

CREATE TABLE orders (
  id uuid PRIMARY KEY DEFAULT uuidv7(),
  placed_at timestamptz NOT NULL DEFAULT now()
);

Questions people ask#

Are these UUIDs really unique?

Uniqueness is probabilistic, not guaranteed, and the RFC does not promise otherwise. For v4 the odds are the ones above. For v7, two UUIDs made by this page in the same millisecond can never match, because a counter in the bits after the timestamp increments for each one; across different machines the 62 random bits at the end do the work.

Can I use a UUID as a database primary key?

Yes, and plenty of systems do. Store it in a real 128-bit UUID column rather than as a 36-character string: RFC 9562 section 6.13 recommends binary storage, and PostgreSQL's uuid type holds it in 16 bytes instead of 36 characters. If the table takes a lot of inserts, use v7 so the index stays local.

Should a UUID be uppercase or lowercase?

Either. RFC 9562 says the alphabetic characters "may be all uppercase, all lowercase, or mixed case", for both output and input. Lowercase is what most libraries emit and what PostgreSQL returns, so it is the safer default. Just compare UUIDs case-insensitively, or normalise them before you compare.

What about v1, v3, v5, v6 and v8?

v1 is timestamp-based and traditionally embeds the machine's MAC address, which the RFC now advises against on privacy grounds. v3 and v5 are name-based: they hash a namespace and a name with MD5 or SHA-1, so the same input always produces the same UUID. v6 is v1 with the timestamp reordered so it sorts, meant for systems already committed to v1. v8 is a free-form version for custom layouts. This page generates v4 and v7, and the inspector reads the version and timestamp of any of them, including v1 and v6.

How many can I generate at once?

Up to 1000 per batch. Ask for more and the count is clamped. For v7, a batch of 1000 is guaranteed to be in ascending order even if the whole batch is produced within one millisecond, using the dedicated counter approach from RFC 9562 section 6.2.