Generate GUIDs and UUIDs (v1, v4, v7) instantly. Bulk generation, format options, and copy to clipboard. Free online UUID/GUID generator — no signup needed.
Generate version 4 (random), version 1 (time-based), and version 7 (time-ordered) UUIDs — also called GUIDs — directly in your browser. Choose a version, generate one or many at once, and copy them with a click. Nothing is sent to a server: every identifier is produced locally from the browser cryptographic random source.
A client-side generator means the values never travel over the network, so you can create keys for production systems, seed data, or test fixtures without exposing anything. The bulk option produces a whole column of identifiers to paste straight into a migration or spreadsheet.
GUID (globally unique identifier) is the Microsoft name for the same 128-bit value. The format is identical, so a GUID generator and a UUID generator produce interchangeable output.
For related developer work, see the JSON formatter and the Base64 encoder / decoder.
A UUID (Universally Unique Identifier) generator creates 128-bit identifiers that are guaranteed to be unique across space and time without requiring a central registration authority. UUIDs are formatted as 32 hexadecimal characters displayed in five groups separated by hyphens: 550e8400-e29b-41d4-a716-446655440000. They are fundamental to distributed systems, databases, and APIs where globally unique identifiers are needed without coordination between systems.
UUIDs solve a critical problem in distributed computing: how do independent systems create identifiers that will never collide? Auto-incrementing database IDs work within a single database but fail when merging data from multiple sources, synchronizing offline clients, or building microservices architectures. UUIDs eliminate this problem entirely.
The UUID specification (RFC 9562, formerly RFC 4122) defines several versions, each generating uniqueness through different mechanisms:
| Version | Name | Generation Method | Use Case |
|---|---|---|---|
| v1 | Time-based | Timestamp + MAC address | Legacy systems needing temporal ordering |
| v3 | Name-based (MD5) | MD5 hash of namespace + name | Deterministic IDs from known inputs |
| v4 | Random | 122 bits of random data | General-purpose unique identifiers |
| v5 | Name-based (SHA-1) | SHA-1 hash of namespace + name | Deterministic IDs (preferred over v3) |
| v7 | Time-ordered | Unix timestamp + random data | Sortable IDs for databases (newest) |
UUID v4 is the most commonly used version. With 122 random bits, the probability of generating two identical UUIDs is astronomically low—you would need to generate 2.71 × 10^18 UUIDs before having a 50% chance of a single collision.
UUID v7 (introduced in RFC 9562) is gaining adoption because it embeds a Unix millisecond timestamp in the first 48 bits, making UUIDs naturally sortable by creation time. This significantly improves database index performance compared to random v4 UUIDs.
A UUID (Universally Unique Identifier) is a 128-bit number guaranteed to be unique across space and time without coordination. Format: 8-4-4-4-12 hexadecimal digits (e.g., 550e8400-e29b-41d4-a716-446655440000). Why use UUIDs: (1) Globally unique - No central registry needed, generate anywhere without conflicts. (2) Distributed systems - Multiple systems can generate IDs independently. (3) Merge-safe - Combining databases never creates ID collisions. (4) Security - Non-sequential prevents enumeration attacks. (5) Migration-friendly - Move records between systems without ID conflicts. Use cases: Database primary keys, Microservices communication, File naming, Session IDs, API request IDs, Document identifiers. Alternative: Auto-incrementing integers are simpler but: Reveal record counts, Cause merge conflicts, Enable enumeration attacks, Require coordination. Use UUIDs when: Working with distributed systems, Need globally unique IDs, Merging databases, Building APIs, Prioritizing security.
UUID has multiple versions for different use cases: UUIDv1 (Time-based) - Includes timestamp and MAC address, Sortable chronologically, Reveals creation time and computer MAC, Privacy concern - MAC address is identifiable, Use when: Need chronological sorting, Privacy not a concern. UUIDv4 (Random) - Purely random (122 bits of randomness), No embedded information, Most popular version, Collision probability: 1 in 5.3 × 10^36 for one billion UUIDs per second for 100 years, Use when: Need maximum randomness, Privacy important, No sorting required. UUIDv5 (Name-based SHA-1) - Generated from namespace + name using SHA-1 hash, Deterministic - same input always produces same UUID, Reproducible without storage, Use when: Need reproducible IDs, Deriving UUIDs from existing identifiers, Content-addressable systems. Deprecated: UUIDv2 (DCE Security) - rarely used, UUIDv3 (Name-based MD5) - obsolete, use v5 instead. Recommendation: Use v4 for general purposes, v1 when you need time sorting, v5 when you need deterministic generation.
UUIDs are designed to be unique with astronomically low collision probability: UUIDv4 Collision Math: 122 random bits = 2^122 possible values (5.3 × 10^36), Probability of collision with 1 billion UUIDs per second for 100 years: ~0.0000000001%, Need to generate 2^61 UUIDs to have 50% collision chance, Effectively impossible in practice. However, collisions CAN happen if: Using broken random number generators (Mersenne Twister, poor seeding), Generating millions of UUIDs in tight loops with weak RNG, Virtualization/containerization cloning with same RNG state, Bugs in UUID library implementations. UUIDv1 uniqueness depends on: MAC address uniqueness (generally guaranteed), Clock accuracy and monotonicity, More predictable but still effectively unique. Best practices: Use cryptographically secure random number generators (not Math.random()), Don't implement UUID generation yourself - use tested libraries, Test UUID uniqueness in your application, Consider UUIDv7 (time-ordered) for databases requiring sortability. In practice, if using proper libraries, collisions are not a real concern.
The UUID vs auto-increment debate has important trade-offs: UUIDs as Primary Keys - Pros: Globally unique (merge databases safely), Generate client-side (reduce database roundtrips), Distributed-friendly (multiple services generate IDs), Secure (can't enumerate records), Partition-friendly (distribute across shards). UUIDs as Primary Keys - Cons: Larger storage (16 bytes vs 4-8 bytes for integers), Slower lookups and joins (larger indexes), Random insertion causes index fragmentation (performance hit), Harder to debug (complex values), URL-unfriendly (long identifiers). Auto-Increment Integers - Pros: Small storage (4-8 bytes), Fast lookups and joins (compact indexes), Sequential insertion (better performance), Human-readable, URL-friendly. Auto-Increment Integers - Cons: Database-dependent (hard to merge), Reveal record counts (security/competitive issue), Enumeration attacks (guess valid IDs), Distributed systems problems (coordination needed). Modern solution: UUIDv7 (coming) - Time-ordered UUIDs combining benefits of both. Recommendation: Use auto-increment for: Single database systems, Internal applications, Performance-critical apps. Use UUIDs for: Microservices, APIs, Multi-tenant SaaS, Distributed systems, Security-sensitive apps.
UUID storage varies by database with significant performance implications: PostgreSQL: Native UUID type (16 bytes), use uuid column type, Supports indexes, Very efficient. MySQL 8.0+: Native UUID type, use UUID or BINARY(16), Convert string to binary: UUID_TO_BIN(), Convert back: BIN_TO_UUID(). MySQL 5.7 and earlier: Store as CHAR(36) (wasteful - 36 bytes), Better: Store as BINARY(16), Manual conversion: UNHEX(REPLACE(uuid, '-', '')). SQL Server: Native uniqueidentifier type (16 bytes), Supports indexes, Use NEWSEQUENTIALID() for better performance (reduces fragmentation). MongoDB: Native UUID/GUID support, store as BinData type. Performance Tips: (1) Always store as binary (16 bytes), never as string (36 bytes). (2) Use indexed UUID columns sparingly. (3) Consider UUIDv1 or UUIDv7 for time-ordering (reduces index fragmentation). (4) Partition by UUID prefix if needed. (5) Use covering indexes for UUID lookup queries. Storage comparison: UUID as CHAR(36): 36 bytes, UUID as BINARY(16): 16 bytes (56% savings), Integer as INT: 4 bytes, Integer as BIGINT: 8 bytes. For high-volume systems, the storage difference matters significantly.
UUID generation is built into most languages: JavaScript/Node.js: crypto.randomUUID() (Node 14.17+, browser), require('uuid').v4() (npm package). Python: import uuid, uuid.uuid4() (random), uuid.uuid1() (time-based), uuid.uuid5() (name-based). Java: java.util.UUID, UUID.randomUUID() (v4), UUID.nameUUIDFromBytes() (v3/v5). C#/.NET: System.Guid, Guid.NewGuid() (v4). PHP: uniqid() (not true UUID), Ramsey\\Uuid\\Uuid::uuid4() (proper library). Ruby: require 'securerandom', SecureRandom.uuid. Go: github.com/google/uuid, uuid.New() or uuid.NewRandom(). Rust: use uuid::Uuid, Uuid::new_v4(). SQL: PostgreSQL: gen_random_uuid(), MySQL: UUID(), SQL Server: NEWID(). Key principles: Use built-in crypto-secure functions, Don't implement your own, Avoid Math.random() or similar weak RNGs, Test for uniqueness in critical applications. Most languages have battle-tested UUID libraries - never roll your own.
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are the same thing with minor differences in terminology and presentation: UUID - Standard term (RFC 4122), Used in most technologies and languages, Written with lowercase hex digits (550e8400-e29b-41d4-a716-446655440000), Common in open-source, Linux/Unix, APIs. GUID - Microsoft's term for the same concept, Used primarily in Windows and .NET ecosystem, Often written with uppercase hex digits (550E8400-E29B-41D4-A716-446655440000), Sometimes shown in Windows registry format with braces: {550E8400-E29B-41D4-A716-446655440000}. Technical equivalence: Both are 128-bit identifiers, Same format: 8-4-4-4-12 hex digits, Same generation algorithms, Same uniqueness guarantees, Fully interoperable. Practical differences: Case sensitivity (lowercase vs uppercase is convention, not requirement), Brace formatting (cosmetic), API/function naming (UUID.randomUUID() vs Guid.NewGuid()). Recommendation: Use "UUID" for cross-platform systems, Use "GUID" when working specifically with Microsoft technologies, Convert between formats as needed (trivial - just case and braces), Don't worry about the distinction - they're the same thing.
UUIDv5 is ideal when you need reproducible IDs from existing data: How UUIDv5 works: Takes namespace UUID + name string, Applies SHA-1 hash, Produces deterministic UUID (same input → same output), Version bits set to 5. Use cases: (1) Content-addressed storage - File SHA-256 hash → UUID for referencing. (2) Idempotent API operations - Request parameters → UUID ensures same request gets same ID. (3) Derived identifiers - User email → UUID without storing mapping. (4) Data migration - Old ID → UUID for backward compatibility. (5) Reproducible test data - Generate consistent UUIDs across test runs. Standard namespaces: DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (domain names), URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8 (URLs), OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8 (ISO OIDs), X500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8 (X.500 DNs). Example: uuid5(DNS_NAMESPACE, "example.com") → Always produces same UUID. Don't use v5 for: Primary security identifiers (not random), Session tokens (predictable), One-time codes (not random enough). Recommendation: Use v5 when repeatability matters, v4 when randomness required.