Skip to main content
PulsarKit

UUID generator

Generate UUID v4, v7 and v1 in bulk, up to 10,000 at once, or decode an existing identifier to see its version, variant and timestamp.

How to generate a UUID

  1. 1

    Pick the UUID version

    Choose v4 for pure randomness, v7 when you want identifiers that sort in creation order, or v1 for the classic time-based layout. NIL and MAX give you the two reserved constant values.

  2. 2

    Set how many and how they are formatted

    Generate up to 10,000 at once. Choose upper or lower case, whether hyphens stay, and wrap each value in quotes, braces or a urn:uuid: prefix for pasting straight into code.

  3. 3

    Copy the list or download it

    Copy every generated value to the clipboard in one click, or download the batch as a plain text file or a CSV; v1 and v7 batches include a timestamp column.

Why v7 is replacing v4 for database keys

A v4 UUID is 122 bits of pure randomness, which means a batch of them inserted into a database index arrives in a completely unpredictable order, which scatters writes across the index and hurts performance at scale. A v7 UUID starts with a 48-bit millisecond timestamp, so identifiers generated later always sort after ones generated earlier, giving you the write locality of an auto-incrementing integer while keeping the collision resistance and decentralised generation of a UUID. This tool keeps v7 batches monotonic even within the same millisecond by using the top bits of the random portion as a counter.

Why v1 here never contains a MAC address

The original 1993 definition of UUID v1 built the trailing 48 bits from the network card's MAC address, on the theory that no two computers share one. In a browser that address is not available, and even where it is, embedding a real MAC address in every database row is a device-tracking leak by design. This generator always fills those 48 bits with random bytes and sets the multicast bit, exactly as RFC 9562 permits, so the timestamp-ordering benefit of v1 survives without exposing any hardware identifier.

Every identifier is generated locally

Generation, formatting and decoding all run in this tab using the Web Crypto API. Nothing is sent to a server, and nothing is written to browser storage. A generic "button pressed" event with the version and count, never the identifiers themselves, reaches analytics.

Frequently asked questions

What is the difference between UUID v4 and v7?

v4 is 122 bits of pure randomness with no structure at all. v7 spends its first 48 bits on a millisecond timestamp, so a batch of v7 values sorts in the order it was created, which is useful as a database primary key, while still carrying enough randomness to avoid collisions.

When should I use v7 instead of v4 for database keys?

Use v7 whenever the identifier becomes a primary key or index column: its time ordering keeps new rows physically close together in the index, which is measurably faster to insert than the random scatter a v4 key produces. Use v4 when the value never touches an index, such as a one-off token.

Why doesn't v1 here contain a MAC address?

Browsers cannot read a device's MAC address, and even outside the browser embedding one in every generated identifier would leak which physical machine created it. This tool fills that part of a v1 UUID with random bytes instead, which RFC 9562 explicitly allows.

How likely is a UUID collision?

For v4, generating a billion UUIDs a second for about 85 years gives roughly a 50% chance of a single collision; in practice it does not happen. v7 and v1 add a timestamp on top of randomness, which makes accidental collisions even less likely.

Can I use a UUID as a password or access token?

Not a good idea. A v4 UUID does carry meaningful randomness, but its format is predictable and tools expect it to be public-looking, unlike a token meant to stay secret. Use the dedicated password generator for anything that needs to remain a secret.

What are the NIL and MAX UUIDs for?

NIL (all zeros) is the reserved value meaning "no identifier" or "not set" in many systems. MAX (all ones), defined more recently, is used as a sentinel for "greater than any real UUID" in range queries. Neither is randomly generated; they are fixed constants.

Where does the randomness come from?

The Web Crypto API's crypto.getRandomValues, and crypto.randomUUID directly for v4 where the browser supports it. Math.random is never used anywhere in this tool.

Does decoding a UUID send it anywhere?

No. The decoder reads the version nibble, the variant bits and, for v1 and v7, the embedded timestamp entirely in your browser. The value you paste in never leaves the page.

Related tools