UUID / GUID Generator

How to use this tool

1. Choose a UUID version. Select v4 for random UUIDs (most common), v7 for time-ordered UUIDs (better for database primary keys), v1 for legacy time-based UUIDs, NIL for all zeros, or MAX for all ones.
2. Set the count. Enter how many UUIDs to generate (1–500), or choose a count preset. The list updates automatically.
3. Pick a format. Standard (with hyphens), No Hyphens, UPPERCASE, Braces { } for Microsoft GUID style, or URN for urn:uuid: prefix.
4. Copy your UUIDs. Click Copy beside one UUID, Copy All for the newline-separated list, or Download .txt to save the current results.

What is a UUID / GUID?

A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier), is a 128-bit label standardized by RFC 9562, which obsoletes RFC 4122. It is written as 32 hexadecimal digits in five hyphen-separated groups: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version digit and N encodes the variant.

UUIDs are designed to be unique across space and time without requiring a central issuing authority. A database, a microservice, or a browser tab can generate a UUID locally and be confident it will never collide with one generated anywhere else; the probability of collision for v4 UUIDs is astronomically small (roughly 1 in 5.3 × 10³⁶ per pair).

UUID versions explained

Version 4: Random (recommended for most uses)

UUID v4 fills 122 bits with cryptographically random data and sets the remaining 6 bits to encode the version (4) and variant (10xx). Because it is completely random, v4 is the simplest choice: no coordination, no time dependency, no privacy concerns. It is the most widely used UUID version. Use v4 for session tokens, API keys, database row IDs, or anything that just needs a unique string.

Version 7: Time-ordered (recommended for database primary keys)

UUID v7, standardized in RFC 9562 (May 2024), encodes the Unix millisecond timestamp in the most significant 48 bits, followed by random data. Because newer UUIDs sort higher than older ones, v7 is friendly to B-tree database indexes: inserts always go near the end of the index, avoiding the page splits and fragmentation that random v4 UUIDs cause in high-insert workloads. Use v7 when you need both global uniqueness and natural chronological ordering, for example as primary keys in Postgres, MySQL, or SQLite. The optional monotonic batch counter orders UUIDs generated in one batch that share a millisecond timestamp; it does not coordinate separate browser tabs.

Version 1: Time-based (legacy)

UUID v1 encodes a 60-bit Gregorian timestamp (100-nanosecond intervals since 15 October 1582) plus a clock sequence and node ID. The original spec used the machine's MAC address as the node, which exposed hardware identity. This generator uses a random node ID instead to preserve privacy. v1 is rarely chosen for new projects. v7 provides timestamp ordering with fewer historical quirks.

NIL UUID

The NIL UUID (00000000-0000-0000-0000-000000000000) has all 128 bits set to zero. It is used as a sentinel "no value" or "not initialised" placeholder, analogous to null in typed systems. Some APIs and ORMs use it to mean "auto-assign on insert."

The MAX UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) has all 128 bits set to one. RFC 9562 defines it as a boundary value for comparisons and range checks; it is not intended to serve as a randomly generated identifier.

UUID format options

• Standard: lowercase with hyphens, the canonical textual representation in RFC 9562 (which replaced RFC 4122): 550e8400-e29b-41d4-a716-446655440000. The RFC 9562 canonical form.
• No Hyphens: 32 lowercase hex characters with no separators: 550e8400e29b41d4a716446655440000. Common in compact storage, URLs, and some ORMs.
• UPPERCASE: uppercase letters with hyphens: 550E8400-E29B-41D4-A716-446655440000. Required by some older APIs and Windows registry entries.
• Braces { }: standard UUID wrapped in curly braces: {550e8400-e29b-41d4-a716-446655440000}. The Microsoft GUID format used in COM, Windows Registry, and .NET.
• URN: prefixed with urn:uuid:: urn:uuid:550e8400-e29b-41d4-a716-446655440000. Used in XML namespaces, some RDF systems, and wherever UUIDs appear as URIs.

UUIDv7 vs. UUIDv4 migration guide

UUIDv7 is the new recommendation for database primary keys because its timestamp prefix makes inserts sequential, drastically reducing B-tree index fragmentation in high-write workloads. UUIDv4 remains the better choice for security tokens, session IDs, and API keys where unpredictability is the primary requirement \u2014 its 122 random bits provide more entropy than v7\u2019s 74 random bits. In practice: use v7 for rows in a database, use v4 for anything that must be unguessable.

Database storage size

At one million rows, CHAR(36) wastes 20 MB per UUID column compared to BINARY(16). At a billion rows the difference is 20 GB \u2014 relevant for large-scale systems.

UUID v4 collision probability

UUID v4 has 122 random bits. The probability of a collision when generating n UUIDs is approximately n\u00b2 / 2¹²³. For practical context: generating 1 billion UUIDs per second continuously, you would expect to wait approximately 85 years before seeing a 50% chance of any single collision. For all\n practical purposes, UUID v4 collisions are not a real-world concern.