UUID v4 vs v7

Both are identifiers

A UUID is a 128-bit identifier written as hexadecimal text, commonly in five groups separated by hyphens. It is designed to make accidental collisions very unlikely when different processes create values without a central counter. It does not describe the record, grant access, or make data confidential.

The version number tells you how the bits were produced. The variant bits identify the UUID layout family. Those bits are part of the identifier and should not be removed or replaced by hand-written random text. RFC 9562 describes the current UUID formats used by this guide.

TheDevTab's UUID Generator creates v4 and v7 values locally. It can generate a batch and change the display between uppercase or lowercase and hyphenated or compact text without changing the underlying version.

UUID v4 is random

Version 4 uses random bits with fixed version and variant positions. It is a good default when the application needs an opaque ID and does not need IDs to carry creation order. A v4 value does not reveal when it was generated, which can be useful when identifiers appear in URLs or logs.

Random does not mean impossible to collide, but the space is large enough that a correct v4 generator makes collisions exceptionally unlikely for normal application volumes. The database should still enforce a unique constraint. If a collision occurs, the application needs a retry path instead of assuming a string comparison is enough.

V4 is a poor replacement for a secret. Treat the value as public if it appears in a URL, log, or database reference. Use a purpose-built secret generator for credentials and a password hashing function for passwords.

UUID v7 is time-ordered

Version 7 places a Unix timestamp in milliseconds near the beginning of the identifier and fills the remaining space with random bits. When values are generated by clocks that move forward, their textual and binary order tends to follow creation time. This can reduce the index churn associated with inserting completely random keys into some database indexes.

The ordering is useful, not absolute. Clock corrections, multiple machines, imports, and values generated in the same millisecond can change the order. A v7 UUID is not a full audit record and does not replace a created_at column when exact event time matters. Store an explicit timestamp when the application needs to query or explain time.

Choose v7 when your database and operational tooling benefit from roughly time-ordered IDs. Choose v4 when compatibility, opacity, or an existing schema is more important. Do not switch versions only because a newer format sounds better. Measure index behavior with your real workload.

Formatting and bulk generation

Hyphens are presentation syntax. A standard UUID with hyphens is 36 characters, while the compact form has 32 hexadecimal characters. Confirm the receiving system before removing separators, and keep one canonical representation in logs and tests. Uppercase and lowercase compare the same in a case-insensitive UUID parser, but a text-based test may still care.

Bulk generation is useful for fixtures, imports, and load tests. Generate a small sample, check the target column, then create the full batch. The generator creates values on the device, and the output remains local until you explicitly copy or download it.

Make the choice part of the schema

Document the UUID version in the table or API contract, enforce uniqueness, and say whether hyphens are required. If an external system already sends v4, preserve that contract. If you are designing a new high-write table and rough time ordering helps, test v7 with the actual index and backup patterns.

The short rule is: v4 gives you an opaque random identifier, and v7 gives you an identifier with useful time ordering. Neither is a password. Generate UUID v4 or v7 in the browser when you want to test the format without uploading a seed or a list.