UUID Generator

A UUID generator creates universally unique identifiers, which are 128-bit values used to identify resources across distributed systems without a central authority. It is used by developers, database administrators, and architects who need collision-resistant unique IDs for records, sessions, files, API resources, and distributed events.

How to Use the UUID Generator

1. Select the UUID version you need (version 4 is the most common choice for general use).
2. Choose how many UUIDs to generate if you need a batch.
3. Click the generate button.
4. Copy one or more UUIDs from the output for use in your code or database.
5. Regenerate as many times as needed; each result is independently unique.

The Formula

A UUID is defined by RFC 4122. It is a 128-bit value displayed as 32 hexadecimal characters grouped into five sections separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where M indicates the version and N indicates the variant.

The most widely used versions are:

• Version 1: Generated from the current timestamp and the MAC address of the generating machine. Time-sortable but potentially reveals the host identity.
• Version 4: Generated from 122 bits of cryptographically secure random data. The remaining 6 bits encode the version and variant. This is the recommended version for most applications because it carries no identifying information and has an astronomically low probability of collision.
• Version 5: Generated deterministically from a namespace UUID and a name using SHA-1 hashing. The same namespace and name always produce the same UUID, making it useful for generating stable identifiers from known inputs.

The probability of a version 4 UUID collision is so small that generating 1 billion UUIDs per second for 100 years would yield less than a 50% chance of a single duplicate.

Real-World Example

You are building a REST API where each new user record needs a unique identifier that is not an auto-incrementing integer (to avoid exposing user count and to support distributed databases). You use the UUID generator to produce a sample UUID during development: f47ac10b-58cc-4372-a567-0e02b2c3d479. You store this as the primary key in your users table and reference it in all related records. When the API goes live, your application generates UUIDs programmatically using the same algorithm, ensuring uniqueness across all database shards.

UUID vs CUID vs NanoID

UUID v4 is the most portable and widely supported unique identifier format. However, alternatives exist:

• CUID (Collision-resistant Unique ID): designed to be URL-safe and monotonically increasing within a process, making it well-suited for use in URLs and readable logs.
• NanoID: a smaller, URL-safe alternative to UUID that uses a customisable alphabet and shorter length by default (21 characters versus 36 for UUID).
• ULID (Universally Unique Lexicographically Sortable Identifier): combines a 48-bit timestamp with 80 bits of randomness, producing identifiers that sort chronologically.

UUID v4 remains the standard choice for database primary keys and API resources due to its universal library support.

Reference Table: UUID versions compared

Four UUID versions and what each one is built from. Version 4 is the default choice for identifiers that must not reveal anything. Version 7 suits database keys because it sorts by creation time while keeping a random tail. A version 4 UUID carries 122 random bits, so collisions are not a practical concern.

Worked Example on Screen

The capture below shows UUID Generator after the inputs were entered, with the result on screen. Enter the same values to reproduce it.

Captured from solved.tools on 10 September 2026.

Frequently Asked Questions

Is a UUID truly unique? In practice, yes. UUID v4 uses 122 bits of randomness. The probability of generating two identical UUIDs is negligible for any realistic system. The widely cited comparison is that you would need to generate approximately 2.7 × 10^18 UUIDs to have a 50% chance of a single collision.

Can I use a UUID as a database primary key? Yes, and this is a common pattern. The main trade-off is that UUID primary keys are larger (16 bytes) than integer primary keys (4 or 8 bytes) and do not sort chronologically, which can affect index performance in some databases. UUID v7, a newer version that includes a timestamp prefix, addresses the sorting limitation.

What does each section of a UUID represent in v4? In a version 4 UUID, all sections except the version digit (M) and the variant bits (N) are random. There is no semantic meaning to the different groups of characters; they are purely for visual grouping and historical compatibility with earlier UUID formats.

Are UUIDs case-sensitive? No. UUID hexadecimal characters are case-insensitive. f47ac10b and F47AC10B represent the same value. The convention is to display UUIDs in lowercase, and most libraries and databases normalise to this format.

Random bits by version

Display length says nothing about how much unpredictability a format carries, and the versions differ sharply. A UUID is always 32 hexadecimal characters grouped into five sections, which is 128 bits, but six of those bits are fixed by the format itself: four for the version and two for the variant. Everything else is either random, derived, or copied from the machine that generated it.

The version 1 row is the one people misread. Its 48-bit node field carries the MAC address of the machine, and its clock sequence adds 14 bits, so two version 1 values from the same host are close to consecutive rather than independent. Version 5 has no randomness at all: the same namespace and the same name produce the same identifier every time, which is the point of it. Version 7 packs a 48-bit millisecond timestamp, 12 bits of randomness in one field and 62 in another, giving 74 random bits behind a value that still sorts by time. NanoID at its default alphabet of 64 characters and 21 characters of output gives 21 multiplied by 6, which is 126 bits, four more than a version 4 UUID in a string 15 characters shorter.

Collision arithmetic for version 4

A version 4 UUID draws 122 random bits, so the space holds 2^122 values, which is 5.3169 times 10^36. The chance that a batch contains one or more duplicates follows the birthday problem. For small batches the probability is close to the square of the count divided by twice the space.

The 50 per cent mark sits at 2.7149 times 10^18 values, which is the figure usually quoted as 2.7 times 10^18. Generating a billion values a second, that point arrives after 86.03 years. A hundred years at the same rate produces 3.15576 times 10^18 values, which carries a 60.75 per cent chance of at least one duplicate rather than the less than even chance the questions above describe. The practical conclusion holds for real systems, where the batches are billions of times smaller, but the century-scale example is on the wrong side of the line. Storage is the other cost of that scale: a billion UUIDs is 16 gigabytes of raw 128-bit values, or 36 gigabytes saved as 36-character text.

What the generator returns

The component asks the browser for crypto.randomUUID, which produces version 4 values from the platform's cryptographically secure generator, and nothing leaves the page. The count field accepts whole numbers and clamps them to a range of 1 to 50, so a batch larger than 50 is not available from the interface. An uppercase switch re-renders the same values with capital letters, which is presentational only, since the hexadecimal digits are case-insensitive and libraries normalise to lowercase in any case. Each line has its own copy control, and a copy-all control appears once the batch holds more than one value.

Where crypto.randomUUID is missing the component falls back to Math.random, which is not a cryptographic source. A version 4 UUID built from Math.random still occupies the right shape and still passes a format check, but its bits are predictable from the generator's internal state, so it should not be used as a session token or a secret. Chrome 92, Firefox 95 and Safari 15.4 and later all provide crypto.randomUUID, so on a current browser the fallback path is unlikely to run, and a value generated on a machine that lacks it should be treated as an identifier rather than a key.

The standards behind the versions

The original definition of versions 1 to 5 is RFC 4122, published in 2005, and it is the document this page's formula section refers to. RFC 9562, published in May 2024, obsoletes it and defines versions 6, 7 and 8 while keeping the format of the earlier versions unchanged. Version 7 exists because of a complaint that RFC 4122's own text records: random identifiers scatter across an index, while a timestamp prefix keeps neighbouring rows together in a B-tree. The birthday-bound approximation used in the table above is the standard one, and it matches the exact expression to within a fraction of a per cent at the sizes shown until the probability nears a half.

Also try these free tools:

• Hash Generator
• Unix Timestamp
• Password Generator