Skip to main content
Back to Tools

UUID Generator

Generate random version 4 UUIDs instantly in your browser. Set the quantity, click Generate, and copy each UUID with one click. No signup required.

TL;DR. This tool generates RFC 4122 version 4 UUIDs using crypto.getRandomValues inside your browser. Each UUID is 128 bits (122 random bits plus 6 version/variant bits), formatted as 32 lowercase hex characters in 8-4-4-4-12 groups. Use v4 for session tokens, database row IDs, file names, and anywhere you need a globally unique identifier without a central counter. For database primary keys where insert order matters, prefer UUID v7 which encodes a millisecond timestamp in the high bits for sequential B-tree indexing.

How to use the UUID generator

  1. Set the quantity. Enter a number from 1 to 100 in the Quantity field. Need a single ID for a test record? Leave it at 1. Need to seed a database fixture file? Set it to 50 or 100.
  2. Click Generate UUIDs. Each click produces a fresh batch. The UUIDs are generated using crypto.getRandomValues, the same cryptographic RNG your browser uses for TLS. They are not transmitted anywhere.
  3. Copy individual UUIDs. Click the copy icon on the right of any row to put that UUID on your clipboard. The icon turns green for 2 seconds to confirm the copy.
  4. Paste directly into code. A v4 UUID like 550e8400-e29b-41d4-a716-446655440000 is ready to use as a string literal in any language. Postgres accepts the hyphenated form directly for its native uuid column type.
  5. Regenerate freely. There is no state saved between sessions. Every page load and every click on Generate produces cryptographically independent values with no connection to previous batches.

UUID format and version cheatsheet

The 128-bit UUID value encodes version and variant bits at fixed positions. Everything else depends on the version.

ConceptDetail
Format8-4-4-4-12 hex digits, e.g. 550e8400-e29b-41d4-a716-446655440000
128 bits32 hex characters plus 4 hyphens = 36 total chars in the canonical string
Char 13Version nibble: "4" for v4 random, "7" for v7 time-ordered
Char 17Variant nibble: 8, 9, a, or b for RFC 4122 (most modern UUIDs)
v1Timestamp + MAC address. Sortable but leaks hardware info.
v4122 random bits. Default choice for session tokens, row IDs, file names.
v5SHA-1 hash of a namespace + name. Same input always produces same UUID.
v748-bit ms timestamp + 74 random bits. Time-ordered, ideal for DB primary keys.
Nil UUID00000000-0000-0000-0000-000000000000. Represents "no value" (like null).
Max UUIDffffffff-ffff-ffff-ffff-ffffffffffff. Upper sentinel value (RFC 9562).
PostgresNative uuid type stores 16 bytes. Use gen_random_uuid() for v4 server-side.
MongoDB ObjectId12-byte (24 hex chars): 4-byte timestamp + 5-byte random + 3-byte counter.
URL-safe variantSome systems strip hyphens or use base62. Always document your format.

When to use each UUID version

  • v4 (random) - default for most use cases: Session tokens, API keys, temporary file names, in-memory object IDs, test fixtures. The 122 random bits make collisions statistically impossible at any realistic scale.
  • v7 (time-ordered random) - best for database primary keys: The 48-bit millisecond timestamp prefix means new rows sort after old rows in a B-tree index. This reduces page splits and cache eviction in Postgres, MySQL InnoDB, and SQLite compared to random v4 inserts.
  • v5 (name-based SHA-1) - deterministic IDs from stable inputs: Use when you need the same string to always map to the same UUID: canonical IDs for URLs, content-addressed cache keys, idempotent event deduplication. Pick a fixed namespace UUID and hash it with your input.
  • v1 (timestamp + MAC) - avoid in new systems: Leaks your server's MAC address, which is a minor privacy issue. Not sortable in string form because the timestamp bytes are in a non-sequential order. Use v7 instead for any new time-sortable requirement.

Frequently asked questions

What is a UUID and what are the different versions?+
UUID (Universally Unique Identifier) is a 128-bit label standardised in RFC 4122. Version 1 encodes the current timestamp plus the MAC address of the machine, which makes it time-sortable but leaks hardware info. Version 4 is fully random (122 random bits), making it the safest default for most apps. Version 5 is name-based using SHA-1, so the same input always produces the same UUID, useful for deterministic IDs from a URL or email. Version 7 (RFC 9562, 2024) uses a millisecond Unix timestamp in the high bits plus random bits below, giving both time-ordered sorting and collision resistance. Use v4 for session tokens and row IDs where sort order does not matter; use v7 for database primary keys where index locality improves query performance.
How likely is a v4 UUID collision?+
Extremely unlikely. There are 2^122 possible v4 UUIDs, roughly 5.3 x 10^36. To reach a 50% collision probability you would need to generate about 2.7 x 10^18 UUIDs. At one billion UUIDs per second that would take 85 years. For practical purposes, v4 UUID collisions do not occur. The caveat is that your random number generator must be cryptographically secure; this tool uses the browser's crypto.getRandomValues under the hood via the uuid library.
What does each part of the UUID format mean?+
A UUID looks like 550e8400-e29b-41d4-a716-446655440000. The 32 hex digits are split by hyphens into groups of 8-4-4-4-12. Character 13 (the first digit of the third group) is the version nibble: 4 for v4, 7 for v7. Character 17 (the first digit of the fourth group) is the variant nibble: 8, 9, a, or b for RFC 4122. Everything else is random in a v4 UUID. In a v7 UUID, the first 12 hex characters encode a 48-bit Unix millisecond timestamp, enabling lexicographic sort by creation time.
Should I use UUID or a database auto-increment integer as a primary key?+
Auto-increment integers are smaller (4 or 8 bytes vs 16 bytes), index-friendly, and human-readable in URLs. UUIDs are better when you generate IDs client-side before a DB round-trip, merge records across multiple databases, or need to avoid exposing record counts. UUID v7 is a good middle ground: it is time-ordered so the B-tree index stays mostly sequential (reducing page splits), while still being globally unique across distributed systems. Postgres has a native uuid type that stores 16 bytes efficiently; MongoDB uses ObjectId (12-byte) which serves a similar role.
What is the nil UUID and the max UUID?+
The nil UUID is all zeros: 00000000-0000-0000-0000-000000000000. It is defined in RFC 4122 as the UUID to use when there is no meaningful value, similar to null. The max UUID (RFC 9562) is all ones in hex: ffffffff-ffff-ffff-ffff-ffffffffffff. It is defined as a sentinel for the highest possible value in a UUID range. Neither should be generated as a real identifier.
What is the difference between a UUID and a GUID?+
Functionally nothing. GUID (Globally Unique Identifier) is Microsoft's name for the same concept. Microsoft COM/OLE uses a variant with different byte order (little-endian for the first three fields), sometimes called Microsoft GUID or variant 2. RFC 4122 UUIDs use big-endian encoding throughout. When you copy a GUID from Visual Studio or the Windows registry, the hex digits represent the same 128 bits but the first three groups are byte-swapped compared to RFC 4122 form. For web APIs and databases, always use RFC 4122 format.

Related developer tools

Sponsored

Ad served by Adsterra. OpenAIToolsHub is not responsible for advertiser content.