UUID Generator

Generate UUIDs (v1, v4, v5) in bulk. Format as uppercase, lowercase, or without hyphens.

Developer ToolsFreeNo Signup
UUID Generator
Free Tool

How to use UUID Generator

**What Is a UUID?** A Universally Unique Identifier (UUID) -- also called a Globally Unique Identifier (GUID) in Microsoft ecosystems -- is a 128-bit label standardized by the Internet Engineering Task Force (IETF) in RFC 4122. Every UUID is represented as 32 hexadecimal digits displayed in 5 groups separated by hyphens in the form 8-4-4-4-12, for example: 550e8400-e29b-41d4-a716-446655440000. The primary advantage of UUIDs is that any system can generate them independently without coordination. Unlike auto-incrementing integer IDs (1, 2, 3...) that require a central database to assign each value sequentially, a UUID can be created on any machine, at any time, and remain globally unique. This property makes UUIDs the standard identifier for distributed systems, microservices, and cloud-scale databases. UUID is defined in IETF RFC 4122 (published 2005) and its successor RFC 9562 (published 2024), which added UUID versions v6 and v7. Amazon Web Services, Microsoft Azure, Google Cloud Platform, Stripe, Twilio, and GitHub all use UUID-format identifiers for their APIs and resource naming. **UUID Versions Explained** RFC 4122 defines five original UUID versions, each with a different generation algorithm: **Version 1 (time-based):** Generated from a 60-bit timestamp plus your machine's 48-bit MAC address. Guarantees temporal ordering and uniqueness across machines, but embeds your hardware identifier -- a privacy and security concern. Rarely recommended for new systems. **Version 2 (DCE security):** Incorporates POSIX UID and GID values alongside a timestamp. Extremely rare in practice. You will almost never encounter it in modern software. **Version 3 (name-based, MD5):** Deterministic -- the same namespace UUID plus the same name string always produces the same UUID. Uses MD5 hashing. Useful when you need reproducible identifiers from known inputs, though MD5 is considered weak by modern cryptographic standards. **Version 4 (random):** 122 bits of cryptographically random data. No embedded metadata, no timestamp, no MAC address. The dominant standard for general-purpose UUID generation today. This is what most developers mean when they say "generate a UUID." **Version 5 (name-based, SHA-1):** Identical to v3 but uses SHA-1 hashing instead of MD5. Preferred over v3 for new development. Use when you need deterministic, reproducible UUIDs from a known namespace and name string. RFC 9562 (2024) introduced three additional versions: v6 (reordered time-based for sortability), v7 (Unix millisecond timestamp plus random bits -- ideal for database primary keys), and v8 (custom format for experimental use). UUID v7 is rapidly gaining adoption in PostgreSQL 17+ and modern ORMs including Hibernate 6 and Sequelize 7. **How to Use This UUID Generator** Generating a UUID with this tool takes under 5 seconds: 1. Open the UUID Generator at diztool.com/tools/uuid-generator. 2. Select your desired UUID version from the dropdown. UUID v4 is selected by default -- it is the right choice for 95% of use cases. 3. Enter the number of UUIDs to generate. The tool supports 1 to 100 UUIDs per batch, making it easy to seed test databases or generate bulk identifiers. 4. Click the Generate button. Your UUIDs appear instantly -- all computation runs inside your browser using the Web Crypto API. No data is sent to any server. 5. Click the Copy button next to any UUID to copy it to your clipboard with a single click. 6. Paste your UUID into your database schema, API payload, configuration file, or anywhere a unique identifier is required. All UUIDs are generated using the Web Crypto API's crypto.randomUUID() function, which provides cryptographically secure random values guaranteed by your operating system's entropy source. Your generated UUIDs are never transmitted or logged. **UUID v4 vs. Other Versions** | Version | Algorithm | Sortable | Privacy Safe | Best Use Case | |---------|-----------|----------|--------------|---------------| | v1 | Timestamp + MAC address | Yes | No -- exposes hardware ID | Legacy systems, ordered logs | | v3 | MD5 hash of namespace + name | No | Yes | Reproducible IDs (legacy) | | v4 | 122 cryptographically random bits | No | Yes | General purpose -- databases, APIs, files | | v5 | SHA-1 hash of namespace + name | No | Yes | Reproducible IDs, deduplication | | v7 | Unix ms timestamp + 74 random bits | Yes | Yes | High-write databases, K-sortable IDs | For new applications, the rule is straightforward: use v4 for random unique identifiers, v5 for deterministic identifiers from known inputs, and v7 for database primary keys where write performance matters. **Real-World UUID Use Cases** UUIDs power the backbone of modern software infrastructure. Here are concrete examples of how major platforms use them in production: **Database Primary Keys:** PostgreSQL natively supports the uuid data type. MySQL 8.0+ provides UUID_TO_BIN() and BIN_TO_UUID() functions for efficient storage. When you design a multi-tenant SaaS application, UUID primary keys allow you to merge data from multiple database shards without ID conflicts -- a critical requirement when handling millions of rows across distributed nodes. **REST API Resource Identifiers:** Stripe identifies every charge, customer, subscription, and payment method with a UUID-format ID (for example: cus_Nffrfepo7AlwBO). GitHub assigns UUID-format node IDs to every repository, user, and issue. AWS uses UUID-format identifiers in every ARN (Amazon Resource Name). When your API returns GET /api/orders/550e8400-e29b-41d4-a716-446655440000, the UUID uniquely identifies that order across every service in your architecture without any shared state. **Distributed Systems and Microservices:** Netflix uses UUIDs as correlation IDs to trace a single user request across 700+ microservices. A UUID generated at the API gateway accompanies every downstream service call, enabling end-to-end distributed tracing. Kafka assigns UUID keys to messages for deduplication across consumer groups processing millions of events per second. **Idempotency Keys:** Stripe, Braintree, and Square support an Idempotency-Key header that accepts a UUID. When a payment request fails mid-flight, you resend the same UUID -- the payment processor deduplicates the request and returns the original response rather than charging the customer twice. This pattern prevents double-charges ranging from a few dollars to tens of thousands of dollars per incident. **File Systems and Operating Systems:** Linux assigns UUID labels to disk partitions (visible via blkid). macOS uses bundle identifiers that internally map to UUIDs. Windows uses GUIDs (the Microsoft term for UUIDs) pervasively throughout COM/OLE infrastructure, the Windows Registry, and Windows Installer package manifests. **Session Tokens and CSRF Protection:** Web frameworks generate UUID v4 values as session identifiers, password reset tokens, and CSRF tokens. A 128-bit random UUID as a session token is computationally infeasible to guess -- an attacker would need approximately 2^122 attempts to find a valid token by brute force. **Common UUID Mistakes** **Mistake 1: Storing UUIDs as VARCHAR(36) instead of the native UUID type** A UUID stored as a string occupies 36 bytes (including 4 hyphens). Stored as raw binary, it occupies 16 bytes -- 56% smaller. On a table with 50 million rows and a UUID primary key, VARCHAR(36) wastes approximately 1 GB of storage compared to BINARY(16). Index size grows proportionally, slowing every query that scans the index. PostgreSQL's native uuid type handles binary storage automatically. In MySQL 8.0+, use UUID_TO_BIN(uuid(), 1) on insert and BIN_TO_UUID(id, 1) on select. **Mistake 2: Using UUID v4 for high-write database tables** UUID v4 is fully random, meaning each new insert lands at a random position in the B-tree index. On tables receiving 5,000+ inserts per second, this causes continuous page splits and index fragmentation, degrading write performance by 30-50% compared to sequential IDs. The solution is UUID v7 (time-ordered) or ULID. UUID v7 prefixes IDs with a millisecond-precision timestamp, enabling sequential index inserts while maintaining global uniqueness. **Mistake 3: Exposing UUID v1 in public APIs** UUID v1 embeds your server's MAC address in bits 80-127 of the identifier. Returning a v1 UUID in an API response reveals your network hardware identifier, server topology, and the exact timestamp of the event. This information has been used in real attacks to map internal network infrastructure and predict future UUID values. Always use v4 or v5 in any public-facing API response. **Mistake 4: Truncating UUIDs to save space** Some developers use only the first 8 characters of a UUID (32 bits) thinking it saves space. With 32-bit IDs, collision probability reaches 50% after generating just 65,536 IDs -- completely unacceptable for any real system. With 16 characters (64 bits), collision probability at 100,000 IDs is roughly 1 in 4 billion -- still risky. Always use the full 128-bit UUID. If you need shorter identifiers, use Base64url encoding (22 characters) rather than truncation. **Mistake 5: Generating UUID-like identifiers with Math.random()** JavaScript's Math.random() is a pseudo-random number generator, not a cryptographically secure one. Its internal state can be predicted by an attacker observing a small number of outputs. Never construct UUID-like values from Math.random(). Always use crypto.randomUUID() (available in Node.js 14.17+, Chrome 92+, Firefox 95+, Safari 15.4+) or crypto.getRandomValues(new Uint8Array(16)) for UUID byte generation. This tool uses crypto.randomUUID() exclusively. **Pro Tips for UUID Implementation** **PostgreSQL built-in UUID generation:** PostgreSQL 13+ includes gen_random_uuid() as a built-in function, returning a cryptographically random v4 UUID with no extension required. Set your primary key column default to gen_random_uuid() and every insert automatically receives a unique identifier without application-side generation. **Namespace UUIDs for reproducible identifiers:** UUID v5 accepts a namespace UUID plus a name string and always produces the same output for the same inputs. The IETF defines standard namespaces in RFC 4122: DNS namespace (6ba7b810-9dad-11d1-80b4-00c04fd430c8) and URL namespace (6ba7b811-9dad-11d1-80b4-00c04fd430c8). Use v5 to generate stable UUIDs from URLs or email addresses -- useful for deduplication pipelines processing millions of records where you need consistent IDs without storing a mapping table. **Database index strategy for UUID primary keys:** For PostgreSQL on write-heavy workloads, consider a BRIN index alongside a UUID v7 primary key. BRIN indexes store ranges of values per disk page and work efficiently when data is inserted in roughly chronological order -- exactly what UUID v7 provides. Index size for a BRIN on a 100-million-row table can be 99% smaller than a standard btree index. **Bulk UUID generation in Node.js:** When seeding test databases or generating batch identifiers, use Array.from({length: 10000}, () => crypto.randomUUID()). This generates 10,000 UUIDs in approximately 15ms on modern hardware using the native crypto module. No third-party library needed. **UUID Technical Specs** The 128-bit UUID is structured using the following format: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx Where x represents a hexadecimal digit (0-9 or a-f), M is the version digit (1 through 7), and N is the variant field (8, 9, a, or b for RFC 4122 compliant UUIDs). For UUID v4 specifically: - Bits 0-47: random (12 hex characters, the first group of 8 plus the first group of 4) - Bits 48-51: version indicator set to binary 0100 (version 4) - Bits 52-63: random (3 hex characters) - Bits 64-65: variant indicator set to binary 10 (RFC 4122) - Bits 66-127: random (15 hex characters plus the last group of 12) Total random bits: 122 Total unique values: 2^122 = approximately 5.3 x 10^36 Collision probability: If every person on Earth (8 billion people) generated 1 billion UUIDs per second, it would take approximately 85 years before the probability of a single collision reached 50%. For all practical purposes, UUID v4 collision risk is zero. Storage formats compared: - Standard string with hyphens: 36 characters - Compact string without hyphens: 32 characters - Binary storage: 16 bytes - Base64url encoded: 22 characters UUID vs. GUID: These terms are fully interchangeable. Microsoft coined GUID (Globally Unique Identifier) for their COM object model in the early 1990s. The byte format, bit layout, and version structure are identical to the IETF UUID standard. Windows generates GUIDs via CoCreateGuid(), producing v4 UUIDs structurally identical to those generated by crypto.randomUUID() in any modern browser. **Why Generate UUIDs in Your Browser?** Many UUID generator websites send your request to a remote server, log the generated values, and store them in analytics databases. This tool generates all UUIDs entirely inside your browser using the Web Crypto API. No data leaves your device, no network request is made, and your UUIDs are never logged or transmitted. This is especially important when generating UUIDs that will be used as security tokens, idempotency keys, or database primary keys -- values that should remain private until you deploy them in your application.

Frequently Asked Questions

What is the difference between a UUID and a GUID?

UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are identical. Microsoft coined GUID for their COM systems in the 1990s, while the IETF standardized UUID in RFC 4122. Both generate 128-bit identifiers with the same 8-4-4-4-12 hexadecimal format. Windows generates GUIDs using CoCreateGuid(), which produces RFC 4122-compliant v4 UUIDs.

Is it possible to generate duplicate UUIDs?

UUID v4 uses 122 random bits, creating approximately 5.3 x 10^36 possible values. If every person on Earth generated 1 billion UUIDs per second for 85 years, the probability of one collision would reach 50%. In practice, duplicates are statistically impossible. AWS, Stripe, and GitHub use UUIDs across billions of records without collision incidents.

Which UUID version should I use for database primary keys?

Use UUID v4 for general-purpose primary keys in read-heavy or moderate-write scenarios. For tables receiving more than 1,000 inserts per second, use UUID v7 instead -- its millisecond timestamp prefix enables chronological sorting, preventing B-tree index fragmentation that causes 30-50% write performance degradation with fully random v4 UUIDs.

Should I store UUIDs as strings or binary in my database?

Binary storage is significantly more efficient. A UUID as VARCHAR(36) occupies 36 bytes; as BINARY(16), only 16 bytes -- 56% smaller. A 100-million-row table saves roughly 2 GB using binary. PostgreSQL's uuid type handles this automatically. In MySQL 8.0+, use UUID_TO_BIN() on insert and BIN_TO_UUID() on select for efficient binary storage.

What is UUID v5 and when should I use it?

UUID v5 is a deterministic version -- the same namespace plus the same name always produces the same UUID, using SHA-1 hashing. Use it when you need reproducible identifiers: mapping a URL to a stable ID, deduplicating records by email address, or generating consistent IDs from known inputs without storing a separate mapping table in your database.

Recommended

Related Tools