UUIDs let independent systems create identifiers without asking one central database for the next number. The ByteKiln UUID Generator creates v4, v7, and v1 values in bulk and validates an existing UUID’s version, variant, and—where applicable—timestamp.
All three versions share the familiar 128-bit 8-4-4-4-12 hexadecimal form, but they encode different tradeoffs.
UUID v4: random and widely supported
Version 4 uses random bits apart from the version and variant markers:
e7c28b70-8b25-4fb4-a8da-6e9cc9720a3dIt is the default choice when you need an opaque identifier and insertion order does not matter. Modern browsers generate v4 values using a cryptographically secure random source. The collision probability is negligible for normal applications, but a UUID is still an identifier—not an authentication secret.
Random values scatter inserts across a database index. That can increase page splits and reduce locality in large, write-heavy tables.
UUID v7: time ordered with random entropy
Version 7 places a Unix timestamp in the high bits and random data in the remainder. Values generated later generally sort later, improving index locality while retaining enough randomness for distributed generation.
v7 is a strong option for new database primary keys when your language, framework, and database ecosystem support it. Because it exposes approximate creation time, do not choose it when that metadata itself must remain hidden.
Generation within the same millisecond may require monotonic handling if strict ordering matters. Treat the timestamp as useful ordering metadata, not as an authoritative event time; store the real creation timestamp in its own column.
UUID v1: legacy time and node structure
Version 1 encodes a timestamp, clock sequence, and node identifier. Traditional implementations used a device MAC address, potentially revealing machine information. Modern libraries may randomize the node component, but v1 remains less attractive for new public identifiers than v4 or v7.
Use v1 primarily when compatibility with an existing system requires it. Validate the behavior of the specific library rather than assuming the node field is private.
Validate before trusting the shape
A string can match the UUID hyphen pattern while containing an unexpected version or variant. The validator reads the relevant bits and extracts timestamps from v1 and v7 values.
Validation confirms format, not provenance. It does not prove that an ID exists, was generated securely, belongs to the current user, or has not been guessed. Authorization must check the requested resource against the authenticated principal regardless of identifier type.
Store UUIDs efficiently
Databases offer several choices:
- a native UUID type, when available;
- a 16-byte binary value;
- a 36-character text representation.
Prefer the native type for clear semantics and compact storage. Text is easy to inspect but consumes more space and may have collation concerns. Binary storage is compact but can require conversion in queries and application tooling.
Keep the canonical lowercase hyphenated form at API boundaries unless an established contract specifies otherwise. Do not alternate among braced, uppercase, hyphenless, and binary forms without a clear normalization rule.
Generate fixtures without accidental coupling
Bulk generation is useful for seed data and tests. Fixed IDs often make tests easier to understand than fresh random IDs on every run:
00000000-0000-4000-8000-000000000101
00000000-0000-4000-8000-000000000102Use newly generated values when testing uniqueness or parsing, but store deterministic fixtures for repeatable relationship tests.
UUIDs versus hashes and tokens
A UUID identifies a record. A hash summarizes input bytes; the Hash Generator is appropriate for checksums and integrity comparisons. A security token grants or proves something and needs sufficient entropy, limited scope, expiration, and secure storage. Do not substitute a visible UUID for an access token.
Selection checklist
- Choose v4 for opaque, random, broadly compatible identifiers.
- Choose v7 for new time-ordered identifiers and better database locality.
- Use v1 only when an existing contract calls for it.
- Store a separate authoritative creation timestamp.
- Prefer a native database UUID type.
- Validate format at boundaries and authorization on every resource request.
- Never treat the difficulty of guessing an ID as access control.
The best UUID version is determined by ordering, privacy, compatibility, and storage requirements—not by uniqueness alone.