🔧 TL3 Tools

What a UUID Generator Does

The TL3 UUID Generator creates universally unique identifiers according to RFC 9562. It supports UUID v4 (random) and UUID v7 (time-ordered with random suffix). UUIDs are generated using crypto.getRandomValues() for cryptographically secure randomness, entirely in your browser. UUID v7 values are time-ordered, making them ideal for use as database primary keys where B-tree index performance matters.

UUID Versions Explained

• UUID v4 — 122 bits of random data. Simple, unpredictable, but scattered across the key space. Best for non-sequential identifiers.
• UUID v7 — 48-bit Unix timestamp (milliseconds) + 74 random bits. Time-ordered values cluster together, improving database index performance.

Generating a UUID

1. Choose UUID version — v4 for random, v7 for time-ordered.
2. Set quantity — generate up to 1,000 UUIDs at once.
3. Select output format — with or without hyphens, uppercase, or wrapped in braces.
4. Click Generate — UUIDs appear in the output area.
5. Copy — use the Copy button or select and copy manually.

Why Teams Use UUIDs

• Software developers — generate UUIDs for database primary keys, API identifiers, and distributed systems
• Database administrators — create UUID v7 keys for better MySQL/PostgreSQL index performance
• Systems integrators — assign unique identifiers across disconnected systems
• Testers and QA — generate bulk test data with unique identifiers

UUID Questions

What's the difference between UUID and GUID?

UUID and GUID are functionally identical. GUID (Globally Unique Identifier) is Microsoft's implementation of the UUID standard. The terms are used interchangeably.

Are generated UUIDs guaranteed to be unique?

UUID v4 uses 122 random bits, so the probability of collision is astronomically low. UUID v7 adds a time component, making collisions essentially impossible when generated on separate machines or at different times.

Why use UUID v7 over v4?

UUID v7 values are time-ordered — they increase over time. This makes them clustered rather than scattered in B-tree indexes. If your database table has a UUID primary key and you care about insert performance or index fragmentation, v7 is significantly better.

Anatomy of a UUID

A UUID is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups — 8-4-4-4-12:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• M is the version nibble (the first digit of the third group). It tells any parser which scheme produced the ID: 4 for v4, 7 for v7, and so on. The generator writes it by masking the random byte and OR-ing in the version bits — bytes[6] = (bytes[6] & 0x0f) | 0x70 for v7.
• N is the variant nibble (the first digit of the fourth group), always 8, 9, a, or b. It marks the bit layout as RFC-compliant so future formats can coexist.
• Everything else is payload. In a v7 UUID the first six bytes are the Unix timestamp in milliseconds, written big-endian, so the ID itself encodes when it was created.

A freshly generated v7 UUID therefore looks like 0196fc11-2a4e-7f82-8a3b-1c9d0e2f4a56: the 7 in group three is the version, the 8 in group four is the variant, and the leading twelve hex digits translate directly back to the moment it was made.

Why Ordering Matters

Because v7 embeds a millisecond timestamp up front, IDs generated moments apart sort in the same order they were created. Inserting them into a B-tree index touches pages that are already in memory instead of scattering writes across the whole key space, which keeps index fragmentation low. The trade-off: two IDs created in the same millisecond order by their random bits, so v7 alone does not guarantee a strict total order — pair it with a sequence number only if you need that.

Randomness and Collisions

The generator pulls bytes from crypto.getRandomValues(), the operating system's cryptographically secure random source — the same one TLS uses. With 122 random bits in a v4 UUID, the birthday bound means you would need to mint roughly 2⁶¹ IDs (about 2.3 quintillion) before reaching a 50% chance of any collision. In practice, collisions are not something to engineer around; generating IDs that leak or can be enumerated is the far more realistic risk.

Storing Them Efficiently

A hyphenated UUID string costs 36 characters. For hot tables, prefer a native uuid column (PostgreSQL, MySQL 8+) or a BINARY(16) column, which stores the same value in 16 bytes. For v7 keys, consider reordering the timestamp bytes before storage so sequential IDs land next to each other on disk — MySQL's UUID_TO_BIN(uuid, 1) does exactly this.

Which Version Should You Pick?

v4 is the default for most applications: purely random, needs no coordination between writers, and reveals nothing about when the ID was created. v7 suits databases where insertion order drives performance, because its leading timestamp keeps freshly written rows adjacent to recently touched ones. v1 encodes the generating machine's MAC address plus a clock sequence — handy for forensics, but it leaks your network hardware's identity, so avoid it in anything user-facing. v3 and v5 derive a UUID by hashing a namespace together with a name, meaning identical inputs always produce identical outputs; that makes them a stable way to build foreign keys without a lookup table.

There is no universally correct answer. Choose by workload: random IDs for public exposure, time-ordered IDs for hot tables, deterministic IDs for reference data, and keep the generator's output format consistent across your codebase so the version stays recognizable years later.