UUID Generator
Free UUID generator. Produce one or many RFC 4122 v4 (random) UUIDs for use as unique identifiers in databases, APIs, and distributed systems.
Quick answer
UUID v4 is a 128-bit random identifier formatted as 8-4-4-4-12 hex digits with dashes. Two specific bits indicate the version (4) and variant (RFC 4122). Collisions are vanishingly improbable: you'd need to generate 2.71 quintillion UUIDs before a 50% chance of any collision.
UUID Generator
How it works
Generates a Version 4 UUID — a 128-bit random identifier in the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The collision probability for UUIDv4 is so low that they're considered globally unique in practice.
When to use it
Use this for database primary keys, file names that need to be unique, session IDs, API request IDs, distributed system identifiers, or any time you need a unique value without coordinating with a central counter.
Common mistakes
Treating UUIDs as secret. UUIDs are designed to be unique, not unguessable — although v4 is random enough that brute-forcing one is impractical, you should still treat sensitive resources with proper auth, not security-by-obscurity.
How the UUID generator works
The tool calls crypto.getRandomValues() from the Web Crypto API to fill a 16-byte buffer. Six specific bits are then set deterministically: 4 bits to mark this as a version 4 (random) UUID, and 2 bits to mark this as a variant 1 (RFC 4122) identifier. The remaining 122 bits are pure randomness. The 16 bytes are formatted as 32 hex characters with dashes at positions 8-12-16-20, producing the canonical 8-4-4-4-12 layout.
When to use it
Generating primary keys for database records when you don't want sequential integers (which leak record counts and timing). Creating opaque external IDs for APIs to avoid exposing internal sequential IDs. Naming temporary files, sessions, or correlation IDs. Generating idempotency keys for API operations. Creating v4 (random) UUIDs for distributed systems where multiple servers must generate non-conflicting IDs without coordination.
Common mistakes
- Using UUID v1 (timestamp-based) when v4 (random) is intended. v1 leaks the host's MAC address and the time of generation. v4 is purely random. This tool generates v4.
- Storing UUIDs as text in databases. A UUID is 16 bytes; the canonical text form is 36 characters. For high-volume tables, storing as binary(16) saves significant space and improves index performance.
- Treating UUIDs as opaque. The version and variant bits are deterministic, so UUIDs aren't truly opaque — but for practical purposes, they're indistinguishable from random and can be used as security tokens (with sufficient additional randomness).
Frequently asked questions
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit identifier formatted as 36 characters with dashes (e.g., 550e8400-e29b-41d4-a716-446655440000). Different versions encode different generation strategies; v4 is the most common — pure randomness.
How likely are UUID collisions?
Vanishingly improbable for v4. You'd need to generate about 2.71 quintillion (2.71 × 10^18) UUIDs before having a 50% chance of a single collision — equivalent to generating 1 billion per second for 85 years.
Should I use UUIDs for database primary keys?
It's a tradeoff. Pros: no collisions across distributed systems, no information leakage. Cons: 4× larger than 32-bit integers, slower for index inserts (random ordering causes B-tree fragmentation). Many systems use UUIDs for external API IDs and integer surrogate keys internally.