UUID Generator

Securely generate Universally Unique Identifiers (UUIDs) client-side. Our generator supports both standard **UUID v4 (Random)** and the new **UUID v7 (Time-Ordered)** specified in the latest IETF RFC 9562 specification.

Ideal for database primary keys, microservice transaction tracing, unique API tokens, and mock test datasets. Generation runs locally in your browser using high-entropy secure cryptography APIs.

Version

Quantity (1-100)

Casing

How UUID Generation Works

UUIDs are generated using structured byte formatting rules defined by the Internet Engineering Task Force (IETF). While the classic versions (like UUID v1) relied on the hardware MAC address and creation timestamps, this created severe security leaks. Modern systems rely on secure random entropy to guarantee uniqueness.

This generator leverages the browser's built-in crypto.randomUUID() API, which pulls high-entropy entropy bytes directly from your operating system's kernel entropy pool (e.g. `/dev/urandom` on UNIX systems or CryptGenRandom on Windows).

UUID v4 vs. UUID v7: Technical Comparison

Specification	UUID v4 (Random)	UUID v7 (Time-Ordered)
Generation Basis	122 random/pseudo-random bits	48-bit Unix epoch timestamp + 74 random bits
Sortable Nature	Unsorted (完全随机)	Chronologically Sortable (lexicographically)
Standards Spec	RFC 4122 (published 2005)	RFC 9562 (supersedes RFC 4122 in 2024)
Clustered Index Friendly	No (causes extreme B-tree fragmentation)	Yes (efficient sequentially ordered entries)
Primary Use Cases	Non-persistent IDs, session tokens, request headers	SQL/NoSQL primary keys, transaction logs, events

UUID Format Anatomy

Anatomy of UUID v4

f47ac10b-58cc-4372-a567-0e02b2c3d479
  │        │    │    │    └─ Node (48 bits random)
  │        │    │    └─ Clock sequence & Variant (16 bits)
  │        │    └─ Version character "4" (4 bits)
  │        └─ Time high (16 bits random)
  └─ Time low & mid (48 bits random)

Anatomy of UUID v7

018fc1e7-8b00-7fa5-b7e1-897c5cb92d04
  │        │    │    │    └─ Random bits (48 bits)
  │        │    │    └─ Variant & Random (16 bits)
  │        │    └─ Version character "7" (4 bits)
  │        └─ Millisecond timestamp (time-low: 16 bits)
  └─ Millisecond timestamp (time-high: 32 bits)

Architectural Use Cases for UUIDs

Modern Relational Databases

When designing tables in Postgres, MySQL, or SQL Server, use UUID v7 as the primary key. This provides the multi-server distribution benefits of a UUID without the massive write-latency penalties of unsorted UUID v4s.

Microservice APIs

Use UUID v4 for request-correlation IDs across distributed services. They are easily generated on any service boundary, ensuring that requests can be traced from entry gate, through queues, to backend microservices.

Offline App Synchronization

In offline-first applications (like mobile apps), clients must generate record IDs without a round-trip to the central server database. Standard UUIDs prevent database constraint conflicts upon synchronization reconnect.

Common UUID Mistakes

Using UUID v4 in SQL clustered indexes: This leads to severe database performance bottlenecks on massive table scaling. Use UUID v7 instead.
Hardcoding test keys: Creating mock databases using static or matching UUIDs throws off indexing constraints and breaks integration testing.
Exposing sensitive timestamp offsets: UUID v1 reveals the MAC address and precise creation time of the generator system, exposing network structures.
Storing UUIDs as plain TEXT: Storing 36-character string representations in SQL takes 36 bytes instead of the binary 16-byte representation.

UUID Best Practices

Store in Native columns: Always define primary keys using the native `UUID` data type (or binary(16)) in your database schemas to save storage.
Use crypto-secure engines: Avoid pseudo-random math loops like Math.random() for high-scale generation to minimize duplicate risks.
Audit legacy UUID v1 systems: Upgrade older systems using UUID v1 to UUID v7 to protect system hardware metadata and optimize write speeds.
Lower-case consistently: Standardize on lower-case representation in API payloads and database inserts to avoid string equality mismatch.

Frequently Asked Questions

What is a UUID and how does it work?

A UUID (Universally Unique Identifier) is a 128-bit value standardized by the Internet Engineering Task Force (IETF) to uniquely identify resources in distributed systems. It is formatted as a 36-character string comprising 32 hexadecimal digits separated by four hyphens in an 8-4-4-4-12 pattern. Because of the sheer size of the identifier space (2^128 or 3.4 x 10^38 possible values), systems can generate UUIDs independently without consulting a central registry, with a mathematically negligible risk of duplication.

What is the difference between UUID v4 and UUID v7?

UUID v4 is generated entirely based on random or pseudo-random bits. It offers maximum uniqueness but has no inherent order, meaning it is unsorted. UUID v7 is a modern standard (RFC 9562) that combines a 48-bit millisecond-precision Unix timestamp with random bits. Because it includes a timestamp at the beginning, UUID v7 is naturally time-ordered (monotonically sortable), making it much more efficient for database primary keys than legacy versions.

How does UUID v7 prevent database index fragmentation?

Traditional databases use B-Tree indexing structures for primary keys. When inserting unsorted keys like UUID v4, the database must continuously rebalance the index tree, resulting in massive page splits, disk fragmentation, and write-performance bottlenecks. Because UUID v7 is time-ordered, new records are appended sequentially to the end of the index. This reduces page splits, optimizes write performance, and maintains high-speed database reads.

How low is the collision probability for UUID v4?

The probability of a collision (two identical UUIDs being generated) is astronomically low. To have a 50% chance of a single collision, you would need to generate 1 billion UUIDs every second for about 85 years (about 2.7 x 10^18 UUIDs in total). In normal application scale, the risk of a UUID collision is practically zero, far lower than the risk of physical server memory corruption or hard drive failures.

Is my generated UUID data secure and private?

Yes, absolutely. All UUID generation processes run entirely inside your browser using secure client-side Web Cryptography APIs (or high-entropy fallbacks). Your generated identifiers, timing data, and configurations are never transmitted to any external server, logged, or saved. This guarantees absolute privacy and data sovereignty for your software development projects.

What are RFC 4122 and RFC 9562 standards?

RFC 4122 is the legacy standard published in 2005 that defined UUID versions 1 through 5. Over the years, the limitations of these early versions (such as MAC address privacy leaks in v1 and unsorted keys in v4) prompted the development of newer variants. In 2024, the IETF published RFC 9562, which supersedes the legacy standard and formally introduces UUID v7 and UUID v8, specifically optimized for modern distributed database and api architectures.

Are UUIDs secure to use for passwords or cryptography?

While UUIDs generated using secure cryptographically random APIs (like our tool) are highly unpredictable, they are not designed to serve as password hashes, encryption keys, or authentication tokens. They lack the computational complexity required for cryptographic secrets. For security-critical tokens or password security, always use dedicated libraries like bcrypt, Argon2, or standard JWT signers.