Skip to content
Go REST

UUID generator (v1, v4, v7) and inspector

Generate UUIDs in your browser. Pick a version, set a count, copy the output. Below the generator there is an inspector that reads back a UUID's version, variant and embedded timestamp.

Output

What is a UUID?

A UUID (Universally Unique Identifier, also called GUID on Microsoft platforms) is a 128-bit number written as 32 hexadecimal digits in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Any system can generate UUIDs on its own, without asking any other system, and they still stay unique with a very high probability.

The current standard is RFC 9562 (May 2024), which replaced RFC 4122. It defines eight versions. v4 and v7 are the ones you will see in modern code, v1 is legacy, and the NIL UUID is the all-zeros placeholder.

When to use this tool

  • Generating a primary key for a new row. Most modern databases store UUIDs as 16-byte columns and let you generate them on the client, which saves a round trip to fetch an auto-increment ID.
  • Building an idempotency key. Add an X-Idempotency-Key: <uuid> header to a POST so that retries do not create the record twice.
  • Filling in a test fixture or a config value. When you need a stable random ID for a seeded record or a feature flag, v4 is the easy choice.
  • Reading back a UUID to debug it. The inspector tells you whether you have a v1, v4 or v7, and for v1 and v7, what time it was made.

How UUIDs work

A UUID is a 16-byte value with two reserved parts. The version (high nibble of byte 6) names the algorithm that made the UUID. The variant (high bits of byte 8) names the layout. Everything else depends on the algorithm.

  • v1: a 60-bit timestamp (100-nanosecond ticks since 1582-10-15 UTC) plus a 14-bit clock sequence and a 48-bit node ID. Old implementations used the host MAC address as the node, which leaks the hardware identity. Modern code uses a random multicast node, and the inspector confirms it.
  • v4: 122 bits of randomness with the version and variant bits fixed. No structure, no order. The simplest UUID to generate and the default for most uses.
  • v7: a 48-bit millisecond timestamp followed by 74 bits of randomness. It sorts by time: v7 UUIDs made close together in time also sort close together as text, which makes B-tree indexes work much better than with v4.
  • NIL: 00000000-0000-0000-0000-000000000000. A defined placeholder that means "no UUID".

Worked examples

  • f47ac10b-58cc-4372-a567-0e02b2c3d479 is a v4 UUID. The 4 at hex digit 13 is the version nibble. The a at hex digit 17 has its high bit set, which marks the RFC 9562 variant.
  • 018d4d34-b7e0-7c50-9b27-3fd9e7a3d2e1 is a v7 UUID. The first 12 hex digits (018d4d34b7e0) are a millisecond timestamp (2024-01-27T23:15:17.088Z); the 7 at hex digit 13 names v7.
  • c232ab00-9414-11ec-b3c8-9e6bdeced846 is a v1 UUID. The 1 at hex digit 13 names v1; the inspector decodes the embedded timestamp (2022-02-22T19:22:22.000Z).
  • NIL (00000000-...) is the v0 or NIL marker. Some libraries use it as "unknown user" or "system actor".

Common mistakes

  • v4 as a primary key. v4 is random, which spreads writes all over the B-tree and slows inserts badly on large tables. If you need UUIDs as primary keys, use v7.
  • Treating UUIDs as secrets. A v4 UUID is hard enough to guess to be a session token, but a v1 or v7 UUID is not: the timestamp prefix makes guessing much easier. Use real random tokens for security.
  • Comparing as strings or as bytes. UUIDs sort differently as 36-character strings (by text) and as 16-byte binary (by number). Use the same one across your whole stack.
  • MAC leak in old v1. Old libraries put the real MAC address into v1 UUIDs. If you see a v1 UUID with the multicast bit (the lowest bit of the first node byte) clear, it probably holds a hardware MAC.
  • Storing as VARCHAR(36). It costs 36 bytes per row and forces string comparison. Use the native UUID type (uuid in Postgres, BINARY(16) in MySQL) for half the storage and faster comparisons.

FAQ

Which UUID version should I use?

For new code, prefer v7. It is random enough for security and sorted by time, which helps database indexes. v4 is the right default if you want pure randomness with no embedded data.

Are UUIDs really unique?

In practice, yes. A v4 UUID has 122 bits of randomness; generating a billion every second for a century gives you about a 50% chance of one collision.

What is the difference between UUID v4 and v7?

v4 is fully random. v7 starts with a 48-bit timestamp, so v7 UUIDs made close together in time sort close together. That is useful for a database primary key.

Does v1 leak my MAC address?

Old v1 includes the host MAC address. This page generates a random multicast node ID instead, so no real hardware identifier leaks. Modern systems usually do the same.

Why is the NIL UUID useful?

NIL (all zeros) is a defined value that means "no UUID". It is useful as a placeholder where the API needs a UUID column but no value applies.