What is the difference between UUID v1, v4, and v7?

UUID v1 encodes a timestamp and the generating machine's MAC address, which can reveal when and where it was created. UUID v4 is fully random, revealing nothing about its origin. UUID v7 encodes a millisecond-precision timestamp in the leading bits, making it time-sortable like v1 but without embedding MAC addresses. For new projects, use v4 for external IDs and v7 for database keys.

Are UUIDs truly unique?

In practice, yes. UUID v4 has 2^122 possible values. The probability of generating two identical UUIDs is so small it is effectively zero for any real workload. The only practical exception is a broken random number generator, such as a virtual machine that restores from a snapshot and reuses the same PRNG state. This tool uses crypto.getRandomValues(), which draws from the OS entropy pool and is not subject to this problem.

Can I use a UUID as an API key?

A UUID v4 provides 122 bits of randomness, which is sufficient entropy for an API key. However, API keys are typically longer (32+ characters base64url-encoded) to allow for a prefix scheme that helps with key rotation and auditing. If you need a simple high-entropy token and do not need key prefixes, UUID v4 works. For production API key generation, consider using a dedicated token library.

Does UUID v7 reveal when a record was created?

Yes. The leading 48 bits of a UUID v7 encode a Unix timestamp in milliseconds. Anyone with access to the UUID can extract the creation time with millisecond precision. If your application should not expose record creation times (for example, in a privacy-sensitive context), use UUID v4 instead and store creation times in a separate column.

What is a ULID and how does it compare to UUID v7?

ULID (Universally Unique Lexicographically Sortable Identifier) predates UUID v7 and serves a similar purpose: time-ordered, sortable unique IDs. ULIDs use a base32 encoding instead of hexadecimal, which produces 26-character strings instead of 36. UUID v7 is now part of the official RFC 9562 standard, which gives it broader ecosystem support. For new projects using standard UUID libraries, v7 is the better choice.

Should I store UUIDs as strings or as binary in the database?

Binary storage (16 bytes) is more efficient than string storage (36 characters). Most databases support a native UUID type or a BINARY(16) column. MySQL's CHAR(36) UUID storage is 36 bytes, which is 2.25x larger than binary. In PostgreSQL, the uuid type stores 16 bytes. For high-volume tables, binary storage meaningfully reduces index size and scan speed.

UUID Generator

This tool generates Universally Unique Identifiers (UUIDs) entirely in your browser using the Web Crypto API. Choose UUID v4 (random), UUID v7 (time-ordered), or UUID v1 (time-based with MAC address stub). Generate one at a time or in bulk. No identifiers are stored, logged, or sent to any server. The tool is free, requires no login, and works offline once the page loads.

VersionQuantity (max 1000)

UppercaseWith hyphensBraces

Generated UUIDs

Validate UUID

How this tool works

The UUID generator produces universally unique identifiers in RFC 4122 format across three versions. Version 1 derives the UUID from the current timestamp and MAC address, producing identifiers that sort chronologically but potentially fingerprinting the generating machine, which is not recommended for public-facing IDs. Version 4 uses cryptographically random bytes for all 122 random bits, producing identifiers with no structural relationship to each other or to the generating environment, making it the recommended default for database primary keys. Version 7 encodes a millisecond-precision Unix timestamp in the first 48 bits followed by random bits, producing identifiers that are both random and monotonically sortable by creation time, useful for database index efficiency without the privacy risk of V1. The tool generates 1-100 identifiers per request and outputs them in the standard 8-4-4-4-12 hyphenated format, in uppercase, lowercase, or without hyphens. All random generation uses the browser's window.crypto.getRandomValues, which is cryptographically secure. Key assumption: V1 generation in the browser approximates the MAC address with a random node value since browsers do not expose network interface hardware addresses. Edge case: UUID V4 collisions are theoretically possible but practically negligible: the probability of a duplicate in 1 trillion generated IDs is approximately 1 in a billion.

Worked example

UUID v5 with the DNS namespace and name "example.com" always returns the same ID on every run. UUID v4 with quantity 10 gives ten different random IDs. Nil returns 00000000-0000-0000-0000-000000000000.

Related tools

Frequently asked questions

What is the difference between UUID v1, v4, and v7?
UUID v1 encodes a timestamp and the generating machine's MAC address, which can reveal when and where it was created. UUID v4 is fully random, revealing nothing about its origin. UUID v7 encodes a millisecond-precision timestamp in the leading bits, making it time-sortable like v1 but without embedding MAC addresses. For new projects, use v4 for external IDs and v7 for database keys.
Are UUIDs truly unique?
In practice, yes. UUID v4 has 2^122 possible values. The probability of generating two identical UUIDs is so small it is effectively zero for any real workload. The only practical exception is a broken random number generator, such as a virtual machine that restores from a snapshot and reuses the same PRNG state. This tool uses crypto.getRandomValues(), which draws from the OS entropy pool and is not subject to this problem.
Can I use a UUID as an API key?
A UUID v4 provides 122 bits of randomness, which is sufficient entropy for an API key. However, API keys are typically longer (32+ characters base64url-encoded) to allow for a prefix scheme that helps with key rotation and auditing. If you need a simple high-entropy token and do not need key prefixes, UUID v4 works. For production API key generation, consider using a dedicated token library.
Does UUID v7 reveal when a record was created?
Yes. The leading 48 bits of a UUID v7 encode a Unix timestamp in milliseconds. Anyone with access to the UUID can extract the creation time with millisecond precision. If your application should not expose record creation times (for example, in a privacy-sensitive context), use UUID v4 instead and store creation times in a separate column.
What is a ULID and how does it compare to UUID v7?
ULID (Universally Unique Lexicographically Sortable Identifier) predates UUID v7 and serves a similar purpose: time-ordered, sortable unique IDs. ULIDs use a base32 encoding instead of hexadecimal, which produces 26-character strings instead of 36. UUID v7 is now part of the official RFC 9562 standard, which gives it broader ecosystem support. For new projects using standard UUID libraries, v7 is the better choice.
Should I store UUIDs as strings or as binary in the database?
Binary storage (16 bytes) is more efficient than string storage (36 characters). Most databases support a native UUID type or a BINARY(16) column. MySQL's CHAR(36) UUID storage is 36 bytes, which is 2.25x larger than binary. In PostgreSQL, the uuid type stores 16 bytes. For high-volume tables, binary storage meaningfully reduces index size and scan speed.