Free UUID Generator Online Tool

Honest Notes on How This Generator Actually Builds a UUID

The "v4" option here produces a correctly-formatted UUID (the version nibble is set to 4, the variant bits are set to RFC 4122's 8/9/a/b pattern), but the randomness underneath comes from Math.random(), not a cryptographically secure source like crypto.getRandomValues() or the browser's native crypto.randomUUID(). For the overwhelming majority of UUID use — primary keys, correlation IDs, record identifiers — this is completely fine, because the goal there is uniqueness, not unguessability, and the 122 random bits still give a collision probability low enough to ignore in practice. But if you intend to use a generated UUID as a secret — an unguessable API token, a password-reset link identifier, a session token — do not use this tool (or any Math.random()-based generator): a predictable PRNG makes such a token theoretically guessable in ways a real security token must not be. Use crypto.randomUUID() or an equivalent CSPRNG-backed call in your actual application code for that case.

The "v1" option is also worth understanding honestly: a real RFC 4122 v1 UUID encodes a 60-bit timestamp in 100-nanosecond intervals since October 15, 1582, plus the generating machine's actual MAC address in the node field. This generator approximates the visual shape of a v1 UUID using Date.now() (millisecond precision, not 100ns) and six random bytes in place of a real MAC address. The output correctly sets the version nibble to 1 and looks like a v1 UUID structurally, but it is not what a canonical v1 library (like Node's uuid package) would produce bit-for-bit, and it will not sort or compare identically to real v1 UUIDs generated elsewhere. One upside of this deviation: because it never touches a real MAC address, it doesn't carry the actual privacy leak that made RFC 4122 v1 controversial in the first place (real v1 UUIDs can be used to fingerprint the originating machine's network hardware).

v1 vs. v4: What the Difference Actually Buys You

Pick v4 unless you have a specific reason not to

A v4 UUID leaks no information about when or where it was created — every bit besides the version/variant markers is random. That's the right default for database primary keys, API resource IDs, and anything shared with a client, because it can't be used to infer creation order or reverse-engineer anything about your system.

Pick v1-style (or a real v1 library) only when rough time-ordering matters

The appeal of a genuine v1 UUID is that IDs generated later sort after IDs generated earlier when compared as strings/bytes in timestamp-first order — useful for certain database index locality patterns (e.g. ULID-style keys exist specifically to formalize this benefit). If you actually need that property in production, use a real, spec-compliant v1/ULID library rather than this browser approximation — this tool is fine for quickly generating something that looks like a v1 UUID for a mockup or test fixture, not for a system that depends on genuine timestamp ordering.

How Unlikely Is a Collision, Really?

A v4 UUID has 122 bits of randomness (128 total bits minus 4 fixed version bits and 2 fixed variant bits). To have a 50% chance of at least one collision, you'd need to generate roughly 2.7 × 10^18 UUIDs — for context, that's billions of UUIDs generated every second for centuries. This is why UUIDs work as unique identifiers without a central coordinating registry: the birthday-paradox math makes accidental collisions a non-issue at any realistic generation volume, even though it's not mathematically impossible.

UUID Format Examples

Standard Format (with hyphens)

550e8400-e29b-41d4-a716-446655440000

Uppercase Format

550E8400-E29B-41D4-A716-446655440000

No Hyphens Format

550e8400e29b41d4a716446655440000

With Braces Format

{550e8400-e29b-41d4-a716-446655440000}

UUID Usage Examples

JavaScript/Node.js

const { v4: uuidv4 } = require('uuid');
const id = uuidv4();
console.log(id);

Python

import uuid
id = uuid.uuid4()
print(id)

Java

UUID id = UUID.randomUUID();
System.out.println(id);

PHP

$id = bin2hex(random_bytes(16));
echo substr_replace(
  $id, '-', 8, 0);

Frequently Asked Questions

Is this v4 generator cryptographically secure?

No — it uses Math.random(), which is fine for generating unique identifiers but is not suitable if you need the UUID to also function as an unguessable secret (a token, a password-reset link ID). For that, use crypto.randomUUID() in your own code instead.

Will the "v1" UUIDs here match what a real UUID v1 library produces?

Not bit-for-bit. This tool approximates the v1 shape using millisecond timestamps and random bytes instead of the spec's 100-nanosecond timestamp and real MAC address, so it looks correct (right version marker, right structure) but won't sort or compare identically to output from a canonical RFC 4122 v1 implementation.

Which version should I default to?

v4, for almost everything — it leaks no timing or machine information and needs no special justification. Only reach for v1-style (or better, a real spec-compliant v1/ULID library) if your system specifically benefits from IDs that sort roughly by creation time.

Do I need to worry about two generated UUIDs colliding?

For v4, no — with 122 random bits, you'd need quintillions of UUIDs before collision probability becomes non-negligible. It's a non-issue at any realistic application scale.

Can I use a generated UUID as a session token or API key?

Not from this tool's v4 output, since it's built on a non-cryptographic random source — a determined attacker with knowledge of the PRNG state could theoretically predict future values. Generate session tokens and API keys with a CSPRNG-backed function on your server instead.