How to Generate a UUID (v4) for a Database or API

You need an identifier for a new database row, an API resource, an upload, or an idempotency key — something guaranteed unique that you can generate before the database hands you one, and that does not leak how many records you have. A UUID v4 is the standard answer.

Here is how to generate one.

How to generate a UUID v4

QuickWand's free UUID Generator creates v4 UUIDs in your browser using cryptographically strong randomness — nothing is generated on or sent to a server.

1. Open the UUID Generator.
2. Copy the generated UUID — something like f47ac10b-58cc-4372-a567-0e02b2c3d479.
3. Need many at once? Set a count and generate them in bulk — handy for seeding a database, building test fixtures, or pre-allocating IDs.
4. Paste into your INSERT statement, API request body, or seed file.

What a UUID v4 actually is

A UUID is a 128-bit identifier, written as 32 hex digits in the familiar 8-4-4-4-12 grouping. The version 4 variant is built almost entirely from random data: 122 of the 128 bits are random, with the remaining few fixed to mark the version (the 4 you can spot as the first digit of the third group) and the variant.

Because it is pure randomness, a v4 UUID needs no central coordination— no sequence, no database round-trip, no shared counter. Any client or service can mint one independently and trust it will not clash with anyone else's.

Will they ever collide?

Effectively never. With 122 random bits there are roughly 5.3 × 10^36 possible values. You would have to generate billions of UUIDs per second for many years before a collision became even remotely likely. For any normal application you can safely treat v4 UUIDs as unique.

UUID vs auto-increment integer

Both make fine primary keys; the trade-offs are different:

• Generate anywhere. A UUID can be created on the client or in any service before the row exists. An auto-increment integer only exists after the database assigns it.
• No information leak. Sequential IDs in a URL reveal your record count and let people enumerate resources (/users/1, /users/2, …). UUIDs do not.
• Cost: size and locality.A UUID is 16 bytes versus 4–8 for an integer, and random v4 values scatter across an index, which can hurt insert performance on large tables.

That last point is why UUID v7 has gained traction: it embeds a timestamp so the values are time-ordered, giving you UUID-style uniqueness and the index-friendly locality of sequential keys. If your tool or database supports v7 and you care about insert performance at scale, it is worth considering. For everything else, v4 remains the simple, dependable default.

One more thing: a UUID is an identifier, not a secret

A v4 UUID is unguessable enough to be hard to enumerate, but it is not a security token — do not use one as a password or an authentication secret. For those, generate proper random secrets with a password generator, and fingerprint data you need to verify with the Hash Generator. Use a UUID for what it is: a unique name for a thing.