Should I use v4 or v7?

v7 if anything sorts them — database keys, logs, filenames. v4 if ordering would reveal how many records you have or how fast they arrive. v7 and ULID both carry their creation time in the readable part, which is sometimes information you do not want to publish.

Are UUIDs really unique?

Randomly, yes: a v4 has 122 random bits, so the chance of a collision across a billion identifiers is around one in a million million. That is why the generation has to be genuinely random — an identifier built from a predictable source collides immediately and looks fine while doing it.

Why does my UUID have a fixed digit in the middle?

Two of the fields are not random. The version digit marks which layout the rest of the fields use, and the variant digit says which of the three reserved ranges the value falls in. A generator that fills all 128 bits and forgets both produces something that looks like a UUID and is not one.

No. They are for reading, and most libraries accept the identifier with or without them. Some databases are more efficient without, because a 36-character string is 36 bytes and a 32-byte one fits more per page.

What is a ULID for, when v7 does the same thing?

The same sorting, in 26 case-insensitive characters with no hyphens, and without the letters I, L, O and U so a hand-read identifier cannot be mistyped into a different one. If identifiers get read aloud to support staff, that is worth the extra characters.

Is a UUID safe to use as a secret?

No. A v4 is not a secret — there is nothing to keep — and a v7 or ULID additionally reveals its own creation time. Use it as an identifier. For anything that must be unguessable, use a token from a cryptographic random source with enough bytes to matter, and treat it as a credential.

Does this send anything anywhere?

No. Identifiers are generated in your tab from the browser's own random source. Nothing is uploaded, nothing is stored, and nothing is logged — each identifier exists only until you reload the page.

UUID & ULID Generator

Generate UUIDs and ULIDs in your browser. v4 for random, v7 or ULID when you need them to sort by time, with the trade-offs explained rather than assumed.

uuid

Random. The safe default.

how many

uuid v40

Nothing generated yet. Press Generate to create 1 UUID v4.

Runs in this browser tab. Nothing is uploaded and nothing is stored — each identifier exists only until you reload.

How to use this tool

A UUID is a 128-bit identifier designed so that two people on different machines, with no coordination, can each generate one and be almost certain they are different. That is the whole requirement, and it explains the odd hyphenated form: it is hex, arranged for reading rather than for speed.

1Pick a type. `v4` is random and is the right answer unless you have a reason.
2Set a count if you need more than one — up to 1,000 at a time.
3Copy individually, or all of them at once, or download as a `.txt` file.

v4 or v7: which one do you want?

This is the decision, and it comes down to one question: does anything need these to sort?

	v4	v7
How it is made	128 random bits	A millisecond timestamp, then random bits
Sorts by time	No	Yes — text order equals time order
Leaks the creation time	No	Yes, to the millisecond
Random bits	122	74

Choose **v7** when the identifier is a database key, or goes into a log, or anything else reads them in order. Because the timestamp is leftmost and fixed width, sorting them as text sorts them by time — which turns an index insert from scattered across a B-tree into an append, and makes logs readable without a separate time column.

Choose **v4** when ordering would tell someone more than you want them to know. A sequential identifier reveals how many records exist and how fast they are arriving. Random identifiers leak neither, at the cost of not sorting.

What the hyphenated form is

A UUID is 32 hexadecimal digits. The hyphens split them 8-4-4-4-12, which matches how the fields are laid out internally and makes the string readable without changing a single bit. Strip them and you have the same identifier, which is why so many libraries accept both.

550e8400-e29b-41d4-a716-446655440000
|------| |---| |---|--|----|--------|
  time_low  |  |  |  |  |  node

Third group's first digit is the VERSION: 4 here.
Fourth group's first digit is the VARIANT, which is 8, 9, a or b.
Neither of those is random - see below.

The same UUID, and where the version lives.

The two fields that are not random

A v4 UUID looks like 128 random hex digits, and it is not. Two of them are fixed, and this is the single most common way a hand-rolled generator produces something that looks like a UUID and is not one.

The third group's first digit is the version, always `4` for a v4. The fourth group's first digit is the variant, and RFC 9562 requires its top two bits to be `10` — so in hex it is `8`, `9`, `a` or `b`. Fill all 128 bits at random and you get a version digit anywhere in `0`–`f` and a variant in `0`–`7` three times out of four. Any library that then switches on the version will not recognise it.

ULID

A ULID solves the same sorting problem as v7 and encodes it differently: 26 characters of Crockford base32 rather than hex. That means no hyphens, and an alphabet with the letters I, L, O and U removed so a hand-read identifier cannot be mistyped into a different one.

It is also case-insensitive by design, so it survives being shouted into a support ticket. If your identifiers are read aloud by people, that is worth more than the 10 extra characters.

v1, and the clock sequence

A v1 UUID is built from a timestamp and a machine identifier, which makes it roughly time-ordered already — but not quite, because two UUIDs generated inside the same 100-nanosecond tick would otherwise be identical. The **clock sequence** is a 14-bit counter that advances between them, and it is the only thing distinguishing two UUIDs from the same tick.

That means a v1 generator has to remember the previous UUID. The first one seeds its sequence randomly — which is what a real implementation does at startup — and every one after it advances from the last. This page keeps that chain for the current tab, which is enough for generating a handful; a service needs to hold the sequence itself, and to seed it once per process so two of them do not share one.

Why not v6?

v6 reorders the v1 fields so the timestamp sorts as text, which is a reasonable idea that v7 does more simply. It is not offered here: an implementation of it on this page was subtly wrong — the reorder dropped part of the clock sequence — and a UUID that looks right and is not is worse than one that is not offered.

Doing it yourself

The point of a UUID is that it needs no coordination, and both platforms can do it in one line. If you are reaching for a library to generate one, that is probably a sign of a bigger dependency than the job needs.

// v4, everywhere modern
crypto.randomUUID()

// v7, and ULID, are not built in yet - they need a little assembly,
// or one of the small libraries that does it. See the page above for
// what you are assembling if you do it yourself.

One line each, no library.

# v4
uuidgen

# Linux, without uuidgen installed
cat /proc/sys/kernel/random/uuid

# macOS
uuidgen | tr 'A-Z' 'a-z'

From a shell, for a fixture or a one-off.

Frequently asked questions

Should I use v4 or v7?: v7 if anything sorts them — database keys, logs, filenames. v4 if ordering would reveal how many records you have or how fast they arrive. v7 and ULID both carry their creation time in the readable part, which is sometimes information you do not want to publish.
Are UUIDs really unique?: Randomly, yes: a v4 has 122 random bits, so the chance of a collision across a billion identifiers is around one in a million million. That is why the generation has to be genuinely random — an identifier built from a predictable source collides immediately and looks fine while doing it.
Why does my UUID have a fixed digit in the middle?: Two of the fields are not random. The version digit marks which layout the rest of the fields use, and the variant digit says which of the three reserved ranges the value falls in. A generator that fills all 128 bits and forgets both produces something that looks like a UUID and is not one.
Do I need hyphens?: No. They are for reading, and most libraries accept the identifier with or without them. Some databases are more efficient without, because a 36-character string is 36 bytes and a 32-byte one fits more per page.
What is a ULID for, when v7 does the same thing?: The same sorting, in 26 case-insensitive characters with no hyphens, and without the letters I, L, O and U so a hand-read identifier cannot be mistyped into a different one. If identifiers get read aloud to support staff, that is worth the extra characters.
Is a UUID safe to use as a secret?: No. A v4 is not a secret — there is nothing to keep — and a v7 or ULID additionally reveals its own creation time. Use it as an identifier. For anything that must be unguessable, use a token from a cryptographic random source with enough bytes to matter, and treat it as a credential.
Does this send anything anywhere?: No. Identifiers are generated in your tab from the browser's own random source. Nothing is uploaded, nothing is stored, and nothing is logged — each identifier exists only until you reload the page.