Skip to main content

UUID Generator

Generate UUID v4 identifiers, single or in bulk.

Reviewed by · Last reviewed

1 UUID
bc03c3c8-c871-4a78-9efa-f2f7f7001fd7

How to Use the UUID Generator

  1. Set the count of UUIDs you need in the number input, anywhere from 1 to 100 at once. For scripted workloads, generate 100 at a time and paste them where needed.
  2. Toggle uppercase if your target system expects the canonical hexadecimal digits in A-F rather than a-f. Both forms are valid per RFC 4122 section 3, but systems often pick one.
  3. Click Generate. A list of freshly generated UUID v4 strings appears below.
  4. Copy individually by clicking any single UUID, or use Copy all to grab the entire list as newline-separated values.
  5. Regenerate as many times as needed. Each click produces a new set - there is no caching, seeding, or re-use.

What the Generator Is Actually Calling

When your browser supports it (every modern release since 2021-2022), the generator calls crypto.randomUUID(), which is specified by WebCrypto to return an RFC 4122 version 4 UUID using cryptographic-quality random bytes from the underlying OS CSPRNG. In older browsers the tool falls back to building the UUID manually: it calls crypto.getRandomValues to fill a 16-byte Uint8Array, sets the version nibble (byte 6, high nibble to 0100) and the variant bits (byte 8, high bits to 10), and formats the result as the canonical xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx string. Both paths satisfy the same entropy guarantees: 122 bits of randomness, with the remaining 6 bits reserved for version and variant markers. No server involvement, no network request, no analytics beacon.

When You Would Generate UUIDs

  • Seeding a new row in a distributed database where no central sequence exists - every microservice can mint IDs independently.
  • Creating API keys or magic-link tokens where unguessability matters more than ordering.
  • Naming temporary files in S3 or R2 so concurrent uploads never collide even without coordination.
  • Generating correlation IDs for logs that span multiple services - a UUID in the X-Request-ID header ties them together.
  • Producing mock data for test fixtures where each row needs a realistic-looking identifier.
  • Creating session tokens for a lightweight web app that does not need full JWT machinery.

Common Pitfalls and Edge Cases

  • Using UUID v4 as a primary key in large OLTP tables. v4 is random, which fragments B-tree indexes and hurts insert performance. ULID or UUID v7 (time-ordered) are better when you need both uniqueness and index locality.
  • Trusting UUID uniqueness as security. Possession of a UUID should not equal authorization. Always combine with a signed token or permission check - UUIDs are just identifiers, not bearer credentials.
  • Storing UUID as VARCHAR(36). It works but wastes 36 bytes when a native UUID type (16 bytes binary) is available. PostgreSQL has a uuid column type; MySQL has BINARY(16); SQL Server has uniqueidentifier. Use them.
  • Uppercase vs lowercase. RFC 4122 declares both valid but recommends lowercase on output and case-insensitive on input. Mixing cases in the same system is the classic source of "UUIDs look equal but compare false" bugs.
  • Comparing UUIDs as strings. Two representations can differ by case, hyphenation, or Braces (the Microsoft GUID style {550e...0000}) and still represent the same value. Parse to binary before comparing.
  • Exposing UUIDs in URLs. This is usually fine because they are unguessable, but it still leaks creation timing (v7) or user count patterns (sequential types). For truly secret identifiers use longer random tokens.

UUID Format and Versions

RFC 4122 (July 2005) defines UUID as a 128-bit value with 32 hexadecimal digits, commonly displayed as five groups separated by hyphens in the pattern 8-4-4-4-12. Five versions are defined in the original RFC: v1 encodes MAC address and timestamp, v2 is a DCE Security variant, v3 is a namespace hash with MD5, v4 is random, and v5 is a namespace hash with SHA-1. RFC 9562 (May 2024) obsoleted RFC 4122 and added versions 6, 7, and 8: v6 reorders v1's timestamp for database-friendly ordering, v7 uses Unix milliseconds plus random bits for monotonically increasing random-ish IDs, and v8 is a custom version for application-specific encodings. The version nibble sits in the third group (13th hex digit); the variant bits are in the fourth group. v4 remains the most common default because it is simple and requires no coordination.

Comparison to Alternatives

On the command line, uuidgen ships on macOS and most Linux distributions and generates v4 by default (v1 with -t). Python has uuid.uuid4(), Node.js has crypto.randomUUID(), Postgres has gen_random_uuid() via pgcrypto or the built-in function since 13. For time-ordered IDs, ULID (Universally Unique Lexicographically Sortable Identifier) from the ulid npm package is a popular alternative that preserves creation order in index scans. Snowflake IDs (Twitter's 64-bit design) and KSUID are other time-ordered options. Use this web tool when you need one or a handful of UUIDs without opening a terminal or spinning up Node - particularly handy when filling out a test fixture or pasting an ID into a bug report.

Frequently Asked Questions

What makes a UUID "v4"?

A UUID v4 is populated almost entirely with random bytes, with just two fields fixed: the version nibble is 0100 (binary) marking it as version 4, and the variant bits are 10 marking it as an RFC 4122 variant. That leaves 122 bits of entropy. Other versions use timestamps, MAC addresses, or namespace hashes for specific tradeoffs, but v4 is the simplest and the one the majority of applications reach for when they need a random identifier with no coordination.

How is this different from crypto.randomUUID in my Node script?

It is literally the same implementation. Your browser and your Node runtime both expose crypto.randomUUID from the WebCrypto API, which draws entropy from the OS-level CSPRNG and formats the result according to RFC 4122 section 4.4. The only difference is context - in Node you call it from a script, here you call it from a web page and see the result in a textarea. UUIDs generated by either path are interchangeable and indistinguishable from each other.

Do UUIDs ever collide?

In theory yes, in practice no. With 122 random bits, the birthday-bound for a 50 percent collision probability is about 2^61 generated UUIDs - roughly 2.3 quintillion. At a rate of one UUID per nanosecond per machine, across all computers on Earth, you would run out of well-optimized database storage before hitting a realistic collision. For any actual application the uniqueness is effectively guaranteed, and you do not need to plan for collision handling.

Is the randomness generated on a server?

No. crypto.randomUUID runs in your browser, pulling entropy from the same OS-level source (CryptGenRandom on Windows, /dev/urandom on Linux, SecRandomCopyBytes on macOS) that the WebCrypto API uses for encryption keys. There is no fetch, no WebSocket, no API call, and no telemetry. You can verify by disabling your network connection after the page loads - UUID generation keeps working because the entropy source is local to your OS.

Is UUID the same as GUID?

Yes, with a minor cosmetic caveat. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit value, and Microsoft conventionally writes them inside curly braces like {550e8400-e29b-41d4-a716-446655440000}. The byte layout in .NET is also little-endian for the first three fields, whereas RFC 4122 specifies big-endian, so raw byte-level comparisons between Windows-generated GUIDs and RFC UUIDs require care. At the string-form level they are interchangeable.

When should I use UUID v7 instead of v4?

Use v7 when you need both global uniqueness and approximate creation-time ordering - typically for primary keys in high-insert-rate tables where random v4 keys cause index fragmentation. The first 48 bits of v7 are a Unix millisecond timestamp, so inserts cluster in the B-tree. Postgres, MySQL, and SQLite all benefit. The downside is that v7 leaks creation timing; if timing is sensitive (you do not want to reveal user count or signup velocity) stick with v4.

Can I generate more than 100 at once?

The UI caps at 100 per click to keep the output readable. For bulk workloads, run the loop in your own code: node -e "for(let i=0;i<10000;i++) console.log(crypto.randomUUID())" produces 10,000 in a second. python -c "import uuid; [print(uuid.uuid4()) for _ in range(10000)]" does the same. The web UI targets interactive use; scripts target batch.

Does canonical form always have four hyphens in 8-4-4-4-12 pattern?

Canonically yes, per RFC 4122. But many tools accept UUIDs without hyphens (32 hex characters in a row) and re-canonicalize them on parse. Some accept braces, some accept urn:uuid: prefixes. When storing or comparing, normalize to a single representation - typically the lowercase hyphenated form - to avoid false negatives. Most SQL databases and language libraries do this normalization automatically when you parse into a UUID type.

Is UUID v4 cryptographically secure?

It is generated with a cryptographic RNG, so predicting the next UUID from an observed sequence is computationally infeasible. That makes v4 suitable for tokens that must be unguessable (password reset links, session IDs for low-value sessions, magic-link identifiers). It is not suitable as the sole authentication mechanism for high-value sessions - combine with HMAC-signed tokens or server-side session storage for anything sensitive. 122 bits of randomness is strong, but longer tokens (256 bits) are standard for JWT secrets and API keys.

What is the overhead of using UUID as a primary key?

Storage: 16 bytes binary or 36 bytes string, versus 4-8 for an integer. B-tree fragmentation on v4 inserts causes write amplification; v7 or v6 avoid this. For Postgres use the uuid type, not VARCHAR(36). For MySQL use BINARY(16) with a helper to render as string.

More Developer Tools