xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where the 4 is the version digit and y is one of 8/9/a/b. Uses crypto.getRandomValues() — safe for security tokens. For database primary keys that need ordering, use UUID v7 instead.Generate RFC 4122 UUID v4 identifiers. Single or bulk, validate existing UUIDs, copy with one click. Uses the browser's cryptographic RNG — safe for tokens and IDs.
Click Generate to create a UUIDPaste a string to check if it is a valid UUID v4
UUID (Universally Unique Identifier) v4 uses random numbers and provides 122 bits of randomness. Ideal for unique IDs, correlation IDs, and non-guessable tokens.
Need API Development?A UUID (Universally Unique Identifier), also called GUID, is a 128-bit identifier defined in RFC 4122 and the updated RFC 9562. It is represented as 32 hexadecimal characters in the canonical 8-4-4-4-12 grouping: 550e8400-e29b-41d4-a716-446655440000. UUID v4 (the version this tool produces) uses 122 bits of randomness plus 4 version bits and 2 variant bits, making collisions astronomically unlikely.
The UUID family includes several generation strategies, each solving a different problem:
Auto-increment integers are 4-8 bytes, cache-friendly, and human-readable, but they expose record counts (?id=1043 reveals you have ~1043 records), create coordination problems in distributed systems, and force a single write authority. UUIDs can be generated independently on any node without coordination — essential for microservices, offline-first mobile apps, and multi-region databases. The trade-off is 16 bytes per ID and potential index fragmentation with v4 (use v7 or a separate clustered key to mitigate).
UUID v4 is a sensible default, but wrong for several common requirements:
crypto.getRandomValues()//dev/urandom is unavailable (old IE, some embedded systems), UUID libraries fall back to Math.random() — which is not cryptographically secure. Never generate auth tokens with a non-CSPRNG UUID.a-f) and uppercase (A-F) hex characters.Theoretically yes; practically no. UUID v4 provides 122 bits of randomness (128 total minus 4 version bits and 2 variant bits). To reach a 50% collision probability, you would need to generate roughly 2.71 × 10¹⁸ UUIDs — that is 2.7 quintillion. Even at a sustained rate of 1 billion UUIDs per second, it would take 85 years to reach that threshold. For context: the UUID specification (RFC 4122) is widely considered collision-free for any practical application.
This tool generates UUID v4 (RFC 4122, random-based). Use v7 (RFC 9562, published 2024) when you need time-ordering — v7 embeds a Unix millisecond timestamp in the first 48 bits, making it sortable and index-friendly in databases. v4 is better when you want ZERO information leakage (no creation time, no MAC address). Rule of thumb: v7 for database primary keys, v4 for tokens, session IDs, and anything exposed publicly.
UUID v4 has 122 bits of entropy, which is plenty for session tokens — more than a 128-bit AES key minus the fixed version/variant bits. Two caveats: (1) make sure your generator uses a CSPRNG (this tool uses `crypto.getRandomValues()`, which is the browser's cryptographic RNG — safe). `Math.random()`-based UUIDs are NOT safe. (2) For API keys where revocation matters, pair the UUID with a prefix (e.g., `sk_live_<uuid>`) so leaked keys can be identified and rotated.
Binary (16 bytes) is always more efficient than string (36 chars = 36 bytes, 72 if UTF-16). PostgreSQL has a native `uuid` type that stores as binary automatically. MySQL/MariaDB: use `BINARY(16)` with `UUID_TO_BIN()`/`BIN_TO_UUID()`. SQL Server: `uniqueidentifier`. For MongoDB: `BinData(4, ...)`. String storage is fine for small tables (<1M rows) and simpler for debugging; binary wins at scale for index size, cache efficiency, and B-tree depth.
Random UUIDs (v4) are not sequential, so inserting them into a clustered index scatters writes across the B-tree, causing page splits and fragmentation. Two fixes: (1) switch to time-ordered UUIDs — v7 in modern systems, `NEWSEQUENTIALID()` in SQL Server, or `UUID_TO_BIN(UUID(), 1)` in MySQL 8+ with the swap flag set, (2) use an auto-increment internal key for the clustered index and keep the UUID as a separate unique column. The second approach is standard at scale (Uber, Stripe, GitHub all do a version of this).
Yes. `crypto.randomUUID()` (available in all modern browsers and Node.js 14.17+) generates RFC 4122 v4 UUIDs using the platform CSPRNG. This tool produces the same format with the same security guarantees. Use the native function in your own code when possible — it avoids shipping a UUID library (~3KB) and matches spec exactly.
Yes. Generation runs entirely in your browser via `crypto.getRandomValues()`. No network request, no logging, no server ever sees your UUIDs. You can disconnect from the internet after loading the page and continue generating. This matters for security-sensitive workflows where a UUID might be used as a one-time token — it is never transmitted.