All free tools

Free tool · No signup

UUID Generator (v4 & v7)

Generate random v4 or time-ordered v7 UUIDs in bulk, or paste one to see its version and when it was made.

Version

122 random bits. The default almost everywhere, and reveals nothing about when or where it was made.

Format

Made in your browser with its cryptographic random number generator. Nothing is sent to a server or saved.

0 UUIDs (v4)

Generating…

Works with any UUID or GUID: with or without hyphens, in braces or as urn:uuid:…

Client side only

Every UUID here is made in your browser with its cryptographic random number generator, crypto.getRandomValues, and the inspector reads pasted UUIDs on your device. Nothing is sent to a server, logged or saved, so the IDs you generate are yours alone, and the tool keeps working with your network turned off once the page has loaded.

What's inside a UUID

A UUID is 128 bits written as 32 hex digits in five groups, 8-4-4-4-12. The first digit of the third group is the version, and the first digit of the fourth group (8, 9, a or b) marks the standard variant from RFC 9562, which replaced RFC 4122 in 2024.

  • v4 is 122 random bits. It says nothing about when or where it was made, which is why it's been the default for years.
  • v7 starts with a 48-bit Unix timestamp in milliseconds, followed by 74 random bits. Sorting v7 UUIDs as text or bytes sorts them by creation time.
  • v1 and v6 also hold a timestamp, but in 100-nanosecond steps since 1582 and with a node ID that was often the machine's MAC address. The inspector reads their time too; for new systems, v7 replaces both.

Why v7 makes a better primary key

Databases keep primary keys in a B-tree index. Random v4 keys land on a random page of that index for every insert, so on a large table most inserts touch a page that isn't in memory, and pages split constantly. v7 keys arrive in order, so inserts append to the end of the index like an auto-increment integer would, while staying unique across servers without a central counter. On busy tables that's the difference between an index that fits in memory and one that doesn't.

UUIDs made in the same millisecond are kept in order too. This tool uses the first 42 bits after the timestamp as a counter that starts at a random value, the approach RFC 9562 describes as method 1, so a bulk batch of 1,000 sorts exactly as it was generated.

When to keep v4

A v7 UUID shows when it was created, to the millisecond. If IDs appear in URLs, that can reveal when a customer signed up or how many orders came in today. Keep v4 for public IDs where that matters, and remember that neither version is an access token: check permissions on every request. If you're planning the database or API for a project, see what I build.

By Muhammad Saif · Updated

Questions, answered.

Are the UUIDs generated on a server?

No. The generator is client side only: UUIDs are made in your browser with its cryptographic random number generator (crypto.getRandomValues), and the inspector reads a pasted UUID on your device. Nothing is sent to a server, logged or saved, so no one else ever sees the IDs you create. The tool keeps working with your network turned off once the page has loaded.

Should I use UUID v4 or v7?

Use v7 for database primary keys and anything you sort by creation time. It starts with a millisecond timestamp, so new rows land at the end of the index instead of at random places, which keeps inserts fast in PostgreSQL, MySQL and SQL Server. Use v4 when an ID shouldn't reveal when it was created, or when a system expects v4. Both are 128 bits and fit the same uuid column.

Can two UUIDs ever be the same?

Not in practice. A v4 UUID has 122 random bits: you'd need to make about 2.7 quintillion of them for a 50% chance of one duplicate. A v7 has 74 bits that are random or a counter within each millisecond; this tool counts up within a millisecond, so a batch never repeats and stays in order. A duplicate needs a broken random number generator, which is why this tool uses the cryptographic one.

Is it safe to show UUIDs in URLs?

Usually, but a UUID is an identifier, not a password. A v7 reveals when it was created, to the millisecond, which can leak things like sign-up dates or order volumes. And neither version should be the only thing protecting a resource: check that the signed-in user may see it. For password-reset links or API keys, use a dedicated random token of 128 bits or more.

How should I store a UUID in a database?

In a native 16-byte type, not a 36-character string. PostgreSQL has a uuid type, and PostgreSQL 18 can generate v7 itself with uuidv7(). In MySQL, use BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID(); SQL Server has uniqueidentifier, though it sorts by different bytes, so v7 order isn't kept there. In application code, Prisma creates v7 with uuid(7), and Python 3.14 adds uuid.uuid7() to the standard library.

What's the difference between a UUID and a GUID?

None in practice: GUID is Microsoft's name for a UUID. Windows tools often show it in uppercase inside braces, like {0192F5C3-A1B2-7C3D-8E4F-5A6B7C8D9E0F}, which you can turn on in the format options. The inspector accepts any spelling: with or without hyphens, braces or a urn:uuid: prefix.