Fun Data Playgrounduuids
Use casesField typesAccount← Generator

UUID generator (v4)

Correctly formatted version-4 UUIDs by the thousand, as a column alongside the rest of your schema — and reproducible from a seed, which a normal UUID generator can never be.

Generate UUIDs →All field types

What it generates

Standard 36-character version-4 UUIDs in canonical 8-4-4-4-12 form, with the version and variant bits set correctly — the 4 in the third group and one of 8, 9, a or b starting the fourth:

id,user_id,created_at
3f2b8c14-7d9e-4a1f-b3c2-9e5d81a06f47,...
c81d4e2a-06b7-4f3d-9a8e-2b5c7f10d934,...
7a9e5c30-4182-4bd6-8f71-3c0e6a2b95d8,...

Anything that parses UUIDs will accept these: uuid.UUID() in Python, UUID.fromString() in Java, Postgres uuid columns, and validators that check the version nibble.

The one thing to know before you use these

These UUIDs come from the generator's seeded pseudo-random number generator, not from a cryptographic source. That is a deliberate trade: it is what makes the same seed produce the same UUIDs every run, which is the entire reason to generate identifiers here rather than in application code.

So: excellent for fixtures, seed scripts, load-test payloads and anything you want to be able to reproduce. Not for session tokens, password-reset links, API keys or anything else where unpredictability is the security property. For those, use your platform's crypto.randomUUID() or equivalent. This distinction matters, and no amount of formatting correctness changes it.

Why reproducible IDs are worth having

A test that creates a record and then asserts against it usually has to capture the generated ID at runtime, which makes the assertion awkward and the failure message vague. With a seeded fixture the ID is known before the test runs, so you can reference it directly:

// seed "orders-v2" always produces this first row
const FIRST_ORDER = '3f2b8c14-7d9e-4a1f-b3c2-9e5d81a06f47';
await page.goto('/orders/' + FIRST_ORDER);

The same applies to fixtures shared across a team: everyone's local database has the same identifiers, so a bug report can quote one.

Keeping them unique

Collisions in a 122-bit random space are not a practical concern at these row counts, but the underlying generator is seeded rather than cryptographic, so if you are loading into a column with a UNIQUE or primary-key constraint, enable the Unique toggle and let the generator guarantee it rather than relying on probability.

Also worth remembering: two exports with the same seed produce the same UUIDs by design. That is a feature when you are re-seeding a database, and a problem when you are appending to one. Change the seed for the second batch.

Foreign keys across tables

Each column is generated independently, so a user_id in an orders table will not match a id in a users table by accident. Generate the parent table first, then paste its ID column into a Custom List field on the child schema — every child row then points at a parent that exists. Repeating some IDs in that list gives you realistic skew instead of a uniform spread. The database seeding guide works through the whole two-pass flow.

UUID v4 or something else?

The generator produces v4 specifically. If your schema uses a sortable identifier — UUID v7, ULID, or a snowflake — those encode a timestamp prefix and are not interchangeable with v4. For a sortable-looking key in a fixture, a Pattern field or a Row Number column is usually closer to what you want than a v4 UUID pretending to be ordered.

Common questions

Are these valid UUID v4 values?

Yes. They use canonical 8-4-4-4-12 formatting with the version nibble set to 4 and the variant bits set to 8, 9, a or b, so standard UUID parsers and validators accept them.

Are they cryptographically secure?

No. They come from a seeded pseudo-random generator so that the same seed reproduces the same values. Use them for test data and fixtures, never for tokens, keys or anything where unpredictability is a security requirement.

Can I generate the same UUIDs again?

Yes — that is the point of the seed. The same seed and schema produce identical UUIDs on every machine, so fixtures can be referenced by ID in test assertions.

How do I make a UUID foreign key match another table?

Generate the parent table first, then paste its ID column into a Custom List field on the child schema. Independent random columns will never line up on their own.

Does it support UUID v1 or v7?

No, the field generates v4 only. Time-ordered identifiers such as v7 or ULID encode a timestamp and are better modelled with a Pattern field or a Row Number column if you need sortability in a fixture.

Related generators