UUID Generator

Generate v4 (random) or v7 (time-ordered) UUIDs in your browser. Uses the Web Crypto API for randomness.

How to use

  1. Pick v4 for random UUIDs or v7 for time-ordered ones.
  2. Set the Count (up to 1000) and click Generate.
  3. Use Copy all to grab the full list, or select a single line manually.

What does it do?

v4 UUIDs are 122 bits of cryptographically strong randomness — the ubiquitous default for idempotency keys, session IDs, and anywhere you want an opaque, unordered identifier. v7 UUIDs embed a 48-bit Unix-millisecond timestamp in the leading bytes, so values generated close in time sort close in lexicographic order. That makes v7 a better fit for database primary keys, where inserts can otherwise fragment a B-tree index.

Example

Three v4 UUIDs (random, no order):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

Three v7 UUIDs generated within the same millisecond (notice the shared prefix):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

Are two UUIDs ever the same?

These are the real pitfalls developers run into when wiring UUIDs into an application:

  • Using v4 where insertion order matters. Indexing 10 M random v4s causes heavy page splits in a B-tree. If you keep v4, either live with the write amplification or switch the primary key to v7.
  • Stripping hyphens and losing the version nibble. f47ac10b58cc4372a5670e02b2c3d479 is still a valid 32-char hex UUID, but the 13th character (4) is the version marker — not a random nibble. Do not assume the whole 32 chars are random.
  • Relying on Math.random(). Older libraries built on Math.random() are not cryptographically strong and can be predictable. Use crypto.randomUUID() (browsers and Node 19+) or a v7 library that reads from crypto.
  • Treating v7 as a timestamp. The leading 48 bits carry time but the rest is random, so two v7s with the same millisecond are not ordered deterministically. Do not rely on tie-breaking.
  • Storing as a VARCHAR(36). It works but doubles storage vs a native 16-byte UUID / BINARY(16) column and slows joins. Use the database's native type (uuid in Postgres, UNIQUEIDENTIFIER in SQL Server).
  • Regex that requires a specific version. /[0-9a-f]8-[0-9a-f]4-4[0-9a-f]3-.../i matches only v4. If you later emit v7, that regex silently rejects valid IDs.

Is my data private?

Yes. We don't save the UUIDs you generate. Every value is shown in the output area and is gone the moment you refresh or close the tab. Nothing is stored, no telemetry is collected on the values, and there's no record on our side of what you generated. Feel free to verify in your browser's developer tools.

Frequently asked questions

What is the difference between UUID v4 and v7?

v4 is 122 bits of randomness plus version and variant markers, with no time component. v7 prefixes a 48-bit Unix-millisecond timestamp and fills the rest with random bits, so v7 values generated close in time sort lexicographically. Use v7 as a database primary key to keep B-tree inserts local; use v4 when you want no ordering signal at all.

Will I ever get a duplicate UUID?

Effectively no. A v4 UUID has 122 random bits, so the probability of any two colliding in a batch of one billion is roughly 10^-18. You would need to generate on the order of 2.7 quintillion v4 UUIDs before reaching a 50% chance of a single collision. Treat unique-generation as a given and do not add a uniqueness check.

Is v4 cryptographically random?

This tool uses crypto.randomUUID() which is required by the spec to pull from a cryptographically strong PRNG. That is enough for session IDs, idempotency keys, and most security tokens. It is not a replacement for a signed token or a long API secret, and you should not derive encryption keys from a UUID.

Is UUID v7 standardised?

Yes. UUID v7 is defined in RFC 9562 (May 2024), which superseded RFC 4122 and formalises v6, v7, and v8 alongside the original versions. Most modern languages have v7 implementations — Postgres, MySQL, and SQL Server all accept v7 values as a UUID column with no change required.

What does the binary form look like and does endianness matter?

A UUID is 16 bytes. The canonical text form groups them as 8-4-4-4-12 hex characters. Bytes are written in network (big-endian) order per RFC 9562, so 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 starts with the byte 0x01. Microsoft GUIDs historically store the first three groups little-endian in memory — watch out when interoping with .NET binary dumps.

Do you save the UUIDs this tool generates?

No. We don't save the UUIDs you generate here. Every value is shown in the output area and is gone the moment you refresh or close the tab — nothing is stored, no telemetry is collected on the values. You're welcome to verify in your browser's developer tools.

Related tools