UUID Generator & Validator

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number used to identify information in computer systems. It's written as 32 hexadecimal digits grouped into five blocks separated by hyphens — the canonical format looks like 550e8400-e29b-41d4-a716-446655440000. That's 8-4-4-4-12 digits, or 36 characters including hyphens.

UUIDs were standardised by the Open Software Foundation in the 1980s and are now defined by RFC 9562 (which superseded RFC 4122). The full 128 bits give a theoretical space of about 3.4 × 10³⁸ possible values — enough that generating two identical UUIDs by accident is astronomically unlikely, provided the generator uses good randomness.

Microsoft's ecosystem calls them GUIDs (Globally Unique Identifiers), and the two terms are effectively interchangeable in practice. The format is identical; only the name differs.

What is UUID v4?

UUID version 4 (v4) is the "random" UUID. Almost every bit of a v4 UUID is random — the exceptions are the version nibble (which is forced to 4) and the variant bits (which are forced to 10xx, following the RFC 4122/9562 variant). Everything else comes from a cryptographically secure random source.

The structure of a v4 UUID, laid out byte by byte:

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
                 ↑    ↑
            version=4  variant (8, 9, a, or b)

That y is one hex digit whose high two bits are 10 — so it can be 8, 9, a, or b. This is the RFC variant field. A v4 UUID with any other character in that position is technically malformed.

How UUID v4 works

In JavaScript, the modern way to generate a v4 UUID is crypto.randomUUID(), part of the Web Crypto API. It's available in all current browsers on secure origins (HTTPS and localhost). When it isn't available, the tool falls back to crypto.getRandomValues(), filling a 16-byte Uint8Array with cryptographically secure random bytes and then setting the version and variant bits manually:

bytes[6] = (bytes[6] & 0x0f) | 0x40;   // version = 4
bytes[8] = (bytes[8] & 0x3f) | 0x80;   // variant = RFC 4122

This tool never uses Math.random(). That would be a critical bug for a UUID generator: Math.random() is not cryptographically secure, its output is predictable from previous values, and it has been shown to collide under load in some engines. Every UUID you see from this tool comes from the browser's CSPRNG.

UUID format

The canonical format is 36 characters: 32 hex digits plus 4 hyphens. This tool also supports a compact form — 32 hex characters, no hyphens — which is used by several systems (for example, the compact form is often what databases store internally when they use a BINARY(16) or UUID column).

Both forms represent the same UUID. The compact form is not a different version or a different identifier. When you toggle between them here, the underlying value never changes.

UUID versions at a glance

RFC 9562 defines versions 1 through 8. They differ in how the 128 bits are allocated:

• v1 — MAC address + timestamp. Sortable but leaks the generating machine's identity.
• v3 — MD5 hash of a namespace + name. Deterministic; same input always produces the same UUID.
• v4 — random. The most common version by far.
• v5 — SHA-1 hash of a namespace + name. Same idea as v3, modern hash.
• v6 — timestamp-first reordering of v1. Sortable and modern.
• v7 — Unix epoch timestamp in the high bits, random in the low bits. Increasingly popular for database keys because it's sortable and doesn't leak host info.
• v8 — fully custom, for experimental or vendor-specific layouts.

This tool generates v4 only. The validator, however, recognises all seven versions and reports which one a given string represents.

UUID vs GUID

Identical concept, different vocabulary. Microsoft's .NET framework, Windows APIs, and SQL Server documentation use "GUID"; the RFCs and the Unix ecosystem use "UUID". A GUID from .NET's Guid.NewGuid() is a v4 UUID. There is no format or semantic difference — the choice of term is purely stylistic.

UUID vs database auto-increment IDs

Both are valid choices, and the trade-offs are well understood:

• Auto-increment integers are compact (4 or 8 bytes), naturally sortable, and cheap to index. But they leak information — the sequence reveals how many rows exist and roughly when each was created — and they're hard to merge across multiple database shards or replicas.
• UUIDs are 16 bytes, globally unique across systems, and easy to generate on the client before the row is inserted. But random v4 UUIDs fragment B-tree indexes because inserts land all over the tree; v7 exists specifically to solve this by making UUIDs time-sortable.

For new projects where sharding or distributed writes are likely, many teams reach for v7. For simpler applications, auto-increment integers remain a solid choice. This tool generates v4, which is the right default when you just need a random, globally unique identifier without any sorting requirement.

When developers use UUIDs

• Database primary keys in distributed systems where rows are written by many services.
• API resource IDs that must not leak creation order or row count.
• Request IDs and correlation IDs for tracing a request across microservices.
• Idempotency keys on POST endpoints — same key, same effect, no duplicate orders.
• Test fixtures and mock users that need to be unique across parallel test runs.
• File names for uploaded objects in blob storage, to avoid collisions without a lock.
• Session and correlation IDs in logs, where uniqueness across hosts matters more than readability.

A very common workflow: a developer writing seed data needs 100 unique user IDs. They open this tool, set the quantity to 100, click Generate, copy all, and paste into a fixture generator. The Universal Data Transformer can then wrap that list into JSON, CSV, or SQL INSERT statements in one step.

Example: UUIDs in test user data

Say you need three test users with unique IDs. Click Generate with quantity 3, then use those values as fixture IDs:

[
  {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "name": "John"
  },
  {
    "id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "name": "Alice"
  },
  {
    "id": "6ba7b810-9dad-41d1-80b4-00c04fd430c8",
    "name": "Bob"
  }
]

Paste that JSON into the JSON Diff tool to compare against a revised version and see exactly which records changed.

Bulk UUID generation

This tool generates up to 1,000 UUIDs per click. The limit is deliberate: each UUID is 36 characters, so 1,000 UUIDs is ~36 KB of text. That renders instantly and remains easy to copy into an editor. Higher quantities would be possible, but would start to feel slow to scroll through and cumbersome to paste into most tools.

Generation itself is fast: crypto.randomUUID() is roughly a nanosecond per call, so 1,000 UUIDs take a fraction of a millisecond. The bottleneck, if any, is rendering 1,000 list rows — which the tool handles in one batch rather than one DOM operation per row.

UUID validation

The validator accepts one UUID or a list (one per line) and reports, for each line:

• Whether the string is a valid UUID at all.
• Which version it claims to be (1, 3, 4, 5, 6, 7, or 8).
• The variant bits (RFC 4122, Microsoft reserved, NCS, or future).
• The format (canonical with hyphens, or compact without).
• For invalid inputs, the specific reason: wrong length, non-hex character, missing hyphens in the wrong place, bad version nibble, bad variant bits, and so on.

Examples of what the validator distinguishes:

550e8400-e29b-41d4-a716-446655440000   ✓ Valid, version 4, RFC variant
550e8400-e29b-31d4-a716-446655440000   ✗ Version nibble is 3, not 4
550e8400-e29b-41d4-a716-44665544000Z   ✗ Non-hex character 'Z' at position 35
hello-world                             ✗ Wrong length (11 chars, expected 36)
550e8400e29b41d4a716446655440000       ✓ Valid, compact form (32 chars)

Batch mode also detects duplicates within the pasted list and reports how many were found — useful when you want to verify that a list of IDs really does contain unique values.

UUID collisions and uniqueness

UUID v4 has 122 random bits (128 minus the 6 fixed bits for version and variant). The probability of two random v4 UUIDs colliding is essentially zero — you'd need to generate roughly 2.7 × 10¹⁸ UUIDs before reaching a 50% chance of a collision. For any realistic workload, collisions don't happen.

That said, "essentially zero" is not "zero". The word "unique" in UUID is aspirational, not mathematically guaranteed. If your application requires absolute uniqueness (for example, a primary key constraint), enforce it at the database layer — don't rely on the probability argument alone. And if you want to detect duplicates in a generated batch here, the tool reports them when present.

UUIDs in APIs and databases

In REST APIs, UUIDs typically appear as path parameters (/users/550e8400-…), body fields ({"id": "…"}), or header values for request correlation. In GraphQL, they're usually declared as the ID scalar. In PostgreSQL, UUIDs are a native type; in MySQL, they're often stored as BINARY(16) for compactness; in SQLite, they're typically TEXT.

When indexing UUIDs as primary keys, remember that random v4 values cause page splits in B-tree indexes. Two common mitigations: use v7 UUIDs (which are time-ordered) instead, or keep the UUID as a business identifier but use an internal auto-increment integer as the physical primary key. Both are valid; the choice depends on your workload.

UUID security limitations

This cannot be said often enough: a UUID is an identifier, not a secret. It is not encryption. It is not a password. It is not an authentication token. If you use a UUID as an "unguessable" resource ID and skip authorization checks on the endpoint that serves it, you have built a system where anyone who sees the UUID can access the resource — an "IDOR" vulnerability. Authorisation must always be enforced independently, based on the caller's identity, not on whether they know the ID.

The version-4 UUID is random enough that guessing a specific value is infeasible, which makes UUIDs a reasonable choice for opaque resource identifiers. But "unguessable" is not the same as "authorised". The two concerns must be handled separately.

Client-side UUID generation

This tool generates UUIDs entirely in your browser. Nothing is sent to a server. You can safely use it to generate IDs for test data, fixtures, and even production values (the cryptographic source is the browser's CSPRNG, which is audited and appropriate for security-sensitive use).

Because generation is client-side, there's no rate limit, no account, and no logging. The generated UUIDs exist only in your browser tab's memory and the clipboard or download target you choose. Close the tab and they're gone.

Common UUID mistakes

• Using Math.random() to build one. It's not cryptographically secure. Use crypto.randomUUID() or crypto.getRandomValues().
• Storing UUIDs as CHAR(36) in a database that has a native UUID type. PostgreSQL's UUID type is 16 bytes; CHAR(36) is 36. That's a 2.25× overhead on every row.
• Setting the wrong variant. A UUID with the wrong bits in position 8 is malformed even if it "looks right". This tool flags that case explicitly.
• Assuming all UUIDs are v4. Many libraries return v1 by default (older Java's UUID.randomUUID() returns v4, but the nameUUIDFromBytes variant returns v3). Always check the version nibble.
• Using UUIDs as passwords or tokens. See the security note above. They are not secrets.
• Trimming hyphens inconsistently. Some systems require hyphens, some forbid them. If you're mixing formats, convert explicitly rather than relying on implicit handling.

Related developer tools

• API Request Builder — send HTTP requests using UUIDs as IDs, request IDs, or idempotency keys.
• Universal Data Transformer — wrap generated UUIDs into JSON, CSV, YAML, or SQL.
• JSON Diff — compare two versions of test data field-by-field.
• JWT Debugger — inspect jti, sub, and other UUID-bearing claims in JWTs.
• Base64 Encoder & Decoder — decode Base64-encoded UUIDs (common in cursors and tokens).
• Regex Tester & Debugger — extract UUIDs from log files or text.
• Unix Timestamp Converter — decode the timestamp portion of v1, v6, and v7 UUIDs to a readable date.
• JSON vs XML comparison guide — background reading for data format decisions.

Frequently asked questions

What is a UUID?

A 128-bit identifier written in 32 hex digits separated by hyphens. Used to name resources, records, and events without collisions across systems.

What does UUID stand for?

Universally Unique Identifier. The RFC uses "universally" in the loose sense of "for practical purposes".

How long is a UUID?

36 characters with hyphens (32 hex digits + 4 hyphens), or 32 characters in compact form. The underlying value is 128 bits = 16 bytes.

What is UUID v4?

The random UUID version. Almost all bits are random; the version nibble is forced to 4 and the variant bits are forced to 10xx.

Is UUID v4 random?

Yes — 122 of the 128 bits are random, sourced from a cryptographically secure random number generator.

Are UUIDs unique?

Practically yes. With 122 random bits, collision is astronomically unlikely for any realistic workload. But for hard guarantees, enforce uniqueness at the database level with a unique constraint.

Can I generate multiple UUIDs?

Yes. Set the quantity up to 1,000 and click Generate. Copy the whole list or download it as TXT, CSV, or JSON.

What is the difference between UUID and GUID?

Nothing functional. GUID is Microsoft's term for the same concept. A GUID from .NET is a v4 UUID.

Can UUIDs be used as database IDs?

Yes, and they're commonly used in distributed systems. Be aware that random v4 UUIDs fragment B-tree indexes; consider v7 (time-ordered) if insert performance matters.

Is a UUID secure?

The random bits come from a CSPRNG, so UUIDs are unguessable. But a UUID is not a secret — treat it as an identifier, not a credential, and enforce authorization separately.

Can I use a UUID as a password?

No. UUIDs are 122 bits of randomness, which is not enough entropy for a password (which should come from a password hashing function like Argon2 or bcrypt). Use a proper credential mechanism.

How do I validate a UUID?

Paste it into the Validate UUID section above. The tool checks length, hex characters, hyphen placement, version nibble, and variant bits, and reports the version and format.

What is UUID v7?

A newer version that places a Unix timestamp in the high bits and random data in the low bits. The result is time-sortable, which is useful for database primary keys. This tool generates v4 only, but the validator recognises v7.

Does this tool store my UUIDs?

No. UUID generation and validation run in your browser; the UUIDs you enter or generate are not uploaded to RKRAJ.IN for this task.