UUID Generator
Generate random UUID v4 identifiers. Supports bulk generation, uppercase, and no-dash formats. 100% client-side.
No data sent to serverRelated Tools
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value defined by RFC 9562 (May 2024, replaces RFC 4122) — designed so any system can generate one without coordination, and the chance of collision is effectively zero. The standard format is 32 hexadecimal digits in five hyphen-separated groups: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx where M indicates the version (1, 4, 7, etc.) and N the variant (8, 9, a, or b for the standard variant).
How "unique" is it really?
UUID v4 uses 122 bits of cryptographically random data (6 bits are reserved for version and variant). The collision probability for v4 is ~1 in 2¹²² ≈ 5.3 × 10³⁶ — astronomically low. By the birthday paradox, you'd need to generate ~2.71 quintillion UUIDs before there's a 50% chance of even one collision. For all practical purposes: safe to assume uniqueness without checking.
Where UUIDs shine
Distributed systems, microservices, mobile apps generating local IDs before sync, log correlation across services (request-id headers), file uploads where you can't risk name collision. UUIDs let you generate IDs offline without needing a central database sequence — critical for multi-region deployments and event sourcing.
How to Use
- Choose how many UUIDs to generate (1 to 100) using the count input.
- Toggle Uppercase if you need
A-Fletters instead ofa-f(Microsoft GUID convention is uppercase). - Toggle No Dashes if you want the 32-character hex form (some databases prefer this).
- Click Generate. Press
Ctrl+Enter/Cmd+Enterto regenerate quickly. - Click Copy on individual UUIDs or Copy All to copy all generated UUIDs (one per line).
Privacy: UUIDs are generated via the browser's native crypto.randomUUID() (WHATWG Web Crypto API) — cryptographically secure, no server contacted.
UUID Versions
RFC 9562 (May 2024) standardizes 8 versions. Most code uses v4 — but for time-sortable IDs, v7 is now the recommended default.
| Version | Source | Time-sortable? | Use case |
|---|---|---|---|
| v1 | MAC address + timestamp | Partial | Legacy. Leaks MAC. |
| v3 | MD5 hash of namespace+name | No | Deterministic IDs from a fixed input |
| v4 | Random (122 bits) | No | Default for general unique IDs |
| v5 | SHA-1 hash of namespace+name | No | Like v3 but stronger hash |
| v6 | Reordered v1 (time-first) | Yes | v1 fix for sortability |
| v7 | Unix-ms timestamp + random | Yes | DB primary keys (preferred 2024+) |
| v8 | Custom (vendor-defined) | Depends | Reserved for custom schemes |
Why v7 matters for databases
Random UUIDs (v4) destroy database B-tree index locality — each insert lands in a random leaf, causing page splits and cache misses. UUID v7 embeds a Unix millisecond timestamp at the start, so newer IDs sort after older ones. Inserts happen sequentially at the end of the index. PostgreSQL, MySQL, and SQLite benchmarks show 10–50× faster bulk inserts with v7 vs v4 for primary keys.
UUID v4 vs ULID vs KSUID vs Snowflake
UUID isn't the only option for distributed unique IDs. Each has different trade-offs.
| ID Type | Bits | String len | Time-sortable | URL-safe |
|---|---|---|---|---|
| UUID v4 | 128 | 36 (with dashes) | No | Yes |
| UUID v7 | 128 | 36 (with dashes) | Yes (ms) | Yes |
| ULID | 128 | 26 (Crockford Base32) | Yes (ms) | Yes |
| KSUID | 160 | 27 (Base62) | Yes (s) | Yes |
| Snowflake (Twitter) | 64 | ~19 digits | Yes (ms) | Yes |
When to pick what
- UUID v4 — when standardization matters more than sortability (most APIs, file IDs)
- UUID v7 — when you want both standard format AND sortable IDs (modern DB primary keys)
- ULID — when you want compact, sortable IDs and don't need UUID format (URLs, public IDs)
- KSUID — when you want second-precision sortability + 160 bits randomness (Segment.io's choice)
- Snowflake — when you must fit IDs in 64-bit integers (Twitter, Discord, Instagram). Requires central worker IDs.
FAQ
Are these UUIDs truly unique?
Functionally yes. UUID v4 uses 122 bits of cryptographically secure randomness via the Web Crypto API. The probability of generating a duplicate is ~1 in 5.3 × 10³⁶ — far smaller than the chance of cosmic ray bit-flip on your hard drive.
UUID vs GUID — same thing?
Yes. UUID is the IETF/RFC term; GUID is Microsoft's term for the same concept. They're 128-bit values with the same format. GUIDs are conventionally written in uppercase with curly braces ({XXXXX...}); UUIDs in lowercase without.
Should I use UUID as my database primary key?
For distributed systems: yes, but use UUID v7 (time-sortable) rather than v4 (random). Random UUIDs hurt B-tree index performance because inserts land in random positions. v7 puts time first, so new IDs append to the end of the index — 10–50× faster bulk inserts.
Can I use this UUID as a security token?
If generated via crypto.randomUUID() (which this tool does): yes, sufficient randomness for session tokens, password reset links, etc. Avoid this for long-term cryptographic keys — use crypto.subtle.generateKey() instead. Never use library functions that fall back to Math.random().
Why does UUID format have those specific characters?
The 13th character is always the version (1–8). The 17th character is always 8, 9, a, or b (variant bits). These fixed positions let parsers validate format quickly. The hyphens are purely decorative — they're not encoded into the 128 data bits.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.
📖 Related Guides
UUID v4 vs ULID — Which to Choose?
Compare UUID v4 and ULID for distributed systems. Performance, sortability, and use cases.
Cron Expression Cheatsheet
Cron syntax reference with common patterns. Quartz vs Linux cron differences.
JWT Anatomy — Header, Payload, Signature
Understand JWT structure, claims, and signing algorithms. Security best practices.