Loading...
Loading...
Free online UUID v4 generator — create single or batch UUIDs for database keys, session tokens, and API resources. Copy all with one click.
A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. UUIDs are designed to be unique across space and time without requiring a central registration authority. They are the standard choice for database primary keys, API resource identifiers, distributed system IDs, and any scenario where IDs must be generated independently across different systems without collision.
UUID v4 is the most common variant, using random numbers for all 128 bits except for 6 bits used to indicate the version (4) and variant. This gives approximately 2^122 possible values — 5.3 × 10^36 — making collisions astronomically unlikely. You could generate 1 billion UUIDs per second for 85 years before reaching a 50% collision probability.
Other UUID versions serve different purposes: UUID v1 uses timestamp + MAC address (traceable to specific machine), UUID v3/v5 use namespace-based deterministic generation (same input = same UUID), and UUID v7 (proposed) encodes a timestamp prefix for database-index-friendly ordering. For most applications, UUID v4 is the right default choice.
Common uses for UUIDs include: database primary keys (avoiding auto-increment collisions in distributed databases), API resource identifiers (unpredictable, non-sequential), session and transaction IDs, event tracing across microservices, and as correlation IDs in logging systems. UUIDs are particularly valuable in microservices and offline-first applications where IDs must be generated without a central server.
Performance considerations: UUID v4 primary keys in databases can cause index fragmentation due to their random nature. UUID v7 or ULID solve this by encoding a time component first. UUIDs are 36 characters as strings (128 bits = 16 bytes binary). Store as binary(16) or use PostgreSQL's native uuid type for optimal performance.
UUIDs are increasingly used in event sourcing and CQRS architectures, where every state change is recorded as an event with a unique identifier. In these patterns, UUIDs allow events to be generated independently across multiple services and later merged without conflicts. This makes them ideal for offline-first applications, IoT device networks, and any system where network connectivity cannot be guaranteed at the moment of ID generation.
No, but the probability of collision is negligible. UUID v4 has 122 random bits — about 5.3 × 10^36 possible values. The chance of collision after generating 1 billion UUIDs is approximately 1 in 10^18. For practical purposes they can be treated as unique.
UUID v4 is purely random. UUID v7 encodes a millisecond-precision timestamp as a prefix, making UUIDs sortable by creation time and reducing database index fragmentation. UUID v7 is becoming the recommended choice for new applications.
UUIDs: better for distributed systems, prevent ID enumeration, can be generated client-side. Auto-increment: faster (integer indexing), smaller storage, human-readable, easier debugging. Choose UUIDs when you need global uniqueness or security against ID guessing.
Yes, but with performance implications. UUID v4 values are random, causing index fragmentation in B-tree indexes. Solutions include using UUID v7 (time-ordered), rearranging UUID bytes for sequential ordering, or using a separate auto-increment integer as the clustered index with UUID as a secondary index. PostgreSQL's native uuid type handles UUIDs more efficiently than MySQL.
A nil UUID is all zeros — 00000000-0000-0000-0000-000000000000. It represents the absence of an ID and is used as a sentinel value in databases and APIs. It can serve as a default for optional foreign keys or indicate an uninitialized or deleted record. Standards recommend avoiding nil UUIDs in business logic where possible.