UUID Generator

A UUID is a 128-bit ID that stays unique without a central authority handing out numbers

A UUID (Universally Unique IDentifier) is a 128-bit, or 16-byte, identifier. It is usually written as 32 hex digits split 8-4-4-4-12, like 0192f3a1-7c4e-7b21-9a3f-5c2d8e1f4a6b. The point is that no server has to hand out sequence numbers: values created independently on different machines are, for practical purposes, never the same. In Microsoft environments the same thing is called a GUID.

The current standard is RFC 9562, published in May 2024, which replaces the long-used RFC 4122. It covers versions 1 through 8, but when you create a new ID you will usually pick one of three. v4 is almost entirely random, v7 puts the creation time at the front so values sort in order, and v5 is name-based, so the same name always produces the same value. This tool generates all three, and for any UUID you paste in, it reads out the version and the timestamp.

When to generate UUIDs yourself

If the database already numbers your rows, why make IDs separately? Because sometimes numbers are assigned in more than one place, or you need the ID before anything is stored.

• Test and sample data: fake data such as 30 users or 200 orders needs many distinct IDs at once. Set a count and paste the result straight in as a JSON array or SQL list.
• IDs decided before saving: an offline app, or a screen that saves in several steps, has to fix IDs before sending anything to the server so the relationships hold. A UUID is unique wherever it is created, so there is no need to wait for a server response.
• Merging data from several sources: tables numbered from 1 at each branch collide when combined. If they used UUIDs from the start, nothing has to be renumbered when you merge.
• File and object names: renaming uploads to UUIDs keeps files with the same original name from overwriting each other.
• Request and job tracing: when one request passes through several services, logging the same UUID in each lets you stitch the scattered records into one trail.
• The same ID for the same thing: for something that already has a unique name, such as an address or a product code, use v5 to always give it the same UUID. Any server computes the same result, so nobody needs to exchange an ID table.

How to use it

1. Pick a version at the top. If you are not sure which, see the version comparison below. On first load, 10 v4 UUIDs are already generated.
2. For v4 and v7, enter a count (1 to 1,000) and press Generate. The 1, 10, 100 and 1,000 buttons generate that many immediately. For v5, choose a namespace and enter one name per line; each line produces one UUID.
3. In the output panel, choose the case (lower or upper), the format (8-4-4-4-12, no hyphens, braces, urn:uuid:) and the output (one per line, JSON array, SQL list). The values stay the same and only the notation changes; what you see in the list is exactly what gets copied and saved.
4. Click a row in the list to expand that UUID in the anatomy view. Copy one with the copy icon at the end of the row or the Copy button in the anatomy view, or move the whole list with Copy all or Save file. In the list, use the arrow keys to move and Enter to copy that row.
5. To inspect a UUID from somewhere else, paste it into the box above the anatomy view. It also reads braces, urn:uuid:, quotes and 32 digits without hyphens, and shows the version and variant, plus the creation time for v7, v1 and v6.

v4, v7 or v5: which one?

The biggest reason to choose v7 is sorting. RFC 9562 explains that with time-ordered UUIDs, new values land close together in a database index, which improves index locality, and the difference from inserting random values can be 10x or more in practice. On the other hand, the security section of the same document says to use v4 if the UUID is used for security purposes. A v7 carries its creation time as-is, so anyone looking at a public ID can tell when the record was created.

v1 and v6 also carry a timestamp, but they put the device's MAC address in the node field, so RFC 9562 recommends v7 over v1 and v6 whenever possible. v3 is name-based like v5 but uses MD5, and the standard says to use v5 instead of v3 whenever possible. That is why this tool generates only v4, v7 and v5, and reads the other versions only in the inspection box.

How to read a UUID

Within the 36 characters, only two positions are fixed. The 13th character counted without hyphens (the first character of the third group) is the version, and the top two bits of the 17th character (the first character of the fourth group) are the variant. For the RFC 9562 variant the bits are 10, so the 17th character is one of 8, 9, a or b. What fills the remaining 122 bits depends on the version.

Paste the example values from the RFC 9562 appendix into the inspection box and the anatomy view shows the same layout.

The 12 rand_a bits in v7 are up to the generator. They can simply be random, or hold a counter that increases by 1 within the same millisecond, or a finer-grained fraction of time (RFC 9562 6.2). This tool uses the counter approach (Method 1). When a new millisecond starts, the counter begins at an 11-bit random value; within the same millisecond it goes up by 1, and if it passes 4,095 the timestamp is advanced by 1 millisecond. So even when you generate 1,000 at once, list order and string-sort order are the same. The following 62 bits are fresh random data each time.

Formats and lengths

Changing the notation does not change the 128-bit value. Match whatever format the receiving program expects.

RFC 9562 says hex digits may be written in uppercase, lowercase or mixed, and it is the same value. But if a program compares UUIDs as plain strings, uppercase and lowercase count as different values. Within one system, stick to a single notation.

How to generate them in code, databases and the terminal

• Browser, Node.js: randomUUID in W3C Web Cryptography produces only v4.
• Python 3.14 or later: 3.14 added uuid6, uuid7 and uuid8; uuid7 keeps order within the same millisecond using a 42-bit counter.
• PostgreSQL 18: read the version and timestamp with uuid_extract_version(), uuid_extract_timestamp().
• .NET 9 or later: NewGuid produces v4.
• PowerShell: produces a random GUID.
• macOS terminal: prints in uppercase.
• Linux (util-linux): random by default when a good random source is available. Create a v5 with uuidgen --sha1 --namespace @dns --name www.example.com. Depending on your distribution's util-linux version, -7 may be missing.

How small is the chance of a duplicate?

A v4 has 122 random bits, so there are 2¹²², about 5.3 × 10³⁶, possible values. The probability that at least one pair matches among n values is approximated with the birthday-problem formula 1 − e^{−n(n−1)/(2·2122)}.

Reaching a 50% probability takes 2.7 × 10¹⁸ values, which would take about 86 years even at a billion per second. This calculation does assume the random numbers are uniformly distributed. That is why RFC 9562 tells you to use a cryptographically secure random number generator, and this tool uses the browser's crypto.getRandomValues(). The probability is not zero, so for production data put a unique constraint on the column and, if a collision makes a save fail, generate a new value and retry.

With v7, only values created in the same millisecond can collide. Within one generator the counter increases, so they never collide; when different devices create values in the same millisecond, the 62 trailing random bits tell them apart.

Using v7 as a database key

• Store them as binary: RFC 9562 notes that storing a UUID as text uses 288 bits for a 128-bit value, so store it as 128-bit binary whenever you can. If there is a dedicated type, such as the uuid type in PostgreSQL, use it.
• Sort by byte order: v7 values come out in creation order if you compare the bytes from the front, or sort the text alphabetically when it is written in a single case. Mixing uppercase and lowercase breaks the text sort.
• Treat the timestamp as a hint: the first 48 bits of a v7 come from the creating device's clock. RFC 9562 says it does not guarantee how close that time is to real time, and the PostgreSQL documentation says the extracted time is not necessarily identical to the creation time. If you need the exact creation time, keep it in a separate column.
• Let the database generate them: RFC 9562 says that when all data lives in a single database, UUIDs generated by the database preserve order best. Use values from this tool for test data or IDs you have to fix in advance, and for keys that keep accumulating in production, it is better to generate them with a database or server function.

Common mistakes

• Using only the first 8 characters: 8 characters are 32 bits, so the chance of a match reaches 50% at only about 77,000 values. If you want something short, do not treat a truncated value as unique in the way a UUID is.
• Granting access just because someone knows the UUID: the security section of RFC 9562 says not to assume a UUID is hard to guess, and not to use it as a value that grants privilege merely by being held. Even when a UUID is in a shareable URL, you still need a separate permission check.
• Public IDs made with v7: if the user ID in the address bar is a v7, it reveals the sign-up time. Use v4 wherever the time must not be exposed.
• Tiny differences in a v5 name: www.example.com and www.example.com., leading or trailing spaces, and case differences are all different names and give different UUIDs. RFC 9562 also explains that the same name can be written in several ways, and each way gives a different UUID. This tool does not alter the name and computes it as typed, in UTF-8.
• GUIDs with a different byte order: .NET's Guid.ToByteArray() returns the bytes of the first three groups in reversed order. As strings they match, but check the order when you move them as bytes.
• Name-based UUIDs as primary keys: RFC 9562 says not to use a name-based UUID as a primary key, because values that seem permanent, such as a postal code or a license number, often change later.

Limits and cautions

• It generates up to 1,000 at a time. For v5, up to 1,000 name lines are processed.
• The v7 ordering holds only within this page. Order against values created in the same millisecond in another tab or on another device is not guaranteed.
• The v7 timestamp uses this device's clock. If the device clock is wrong, the time inside the UUID is wrong too.
• v5 uses SHA-1. RFC 9562 says a name-based UUID made with another hash such as SHA-256 should be a v8, not a v5, and this tool does not generate v8.
• v1, v3, v6 and v8 are read-only in the inspection box. The node value in v1 and v6 may be the device's MAC address.
• Generated UUIDs disappear when you reload. Copy the list or save it to a file if you need it.

Sources

As of The RFC 9562, W3C Web Cryptography, PostgreSQL 18, Python, .NET, PowerShell and util-linux documentation were checked against the originals on October 22, 2026. The v4, v7 and v5 values in the example tables were cross-checked to give the same results in this tool and in Python 3.14's uuid module, and the probability table was calculated with the formula above.

• 01IETF RFC 9562 — Universally Unique IDentifiers (UUIDs)May 2024, replaces RFC 4122. Section 4 notation, 5.4 v4, 5.5 v5, 5.7 v7, 6.2 monotonicity, 6.11 sorting, 6.13 databases, section 8 security, Appendix A examples
• 02W3C — Web Cryptography API, randomUUIDThe procedure that produces a version 4 UUID as a lowercase string
• 03PostgreSQL 18 — 9.14 UUID Functionsgen_random_uuid, uuidv4, uuidv7, uuid_extract_timestamp, uuid_extract_version
• 04Python documentation — uuiduuid6, uuid7 and uuid8 added in 3.14; uuid7's 42-bit counter
• 05Microsoft Learn — Guid.CreateVersion7Since .NET 9, RFC 9562 version 7
• 06Microsoft Learn — Guid.NewGuidVersion 4 UUID, 122 bits of entropy
• 07Microsoft Learn — Guid.ToByteArrayReverses the order of the first four-byte group and the next two two-byte groups
• 08Microsoft Learn — New-GuidThe PowerShell command that creates a random GUID
• 09uuidgen(1) — util-linux manualRandom by default, -7 (--time-v7), --sha1 --namespace @dns

Frequently asked questions

Tools to use with it