UUID v4 Generator

Generate cryptographically random UUID v4

…

Format

Count:

Also try:UUID v1 Generator UUID v7 Generator UUID v3 Generator UUID v2 Generator ULID Generator NanoID Generator CUID Generator CUID2 Generator UUID Decoder

UUID v4 is the most widely deployed UUID version in modern software. Unlike its siblings that derive bits from a timestamp or a namespace hash, UUID v4 is built entirely from random data — making it the simplest and most portable choice whenever you need a unique identifier that carries no metadata about its origin.

This generator uses crypto.randomUUID(), the native browser and Node.js API, which sources entropy from the operating system's cryptographically secure random number generator — the same source used for TLS key material.

What is UUID v4?

A Universally Unique Identifier (UUID) is a 128-bit label standardised in RFC 4122. It is typically represented as 32 hexadecimal digits grouped by hyphens into the pattern 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

In UUID v4, 122 of the 128 bits are random. The remaining 6 bits are fixed fields mandated by the spec: 4 bits encode the version (0100 = 4) and 2 bits encode the RFC 4122 variant (10). Those fixed bits are why the third group always starts with 4 and the fourth group always starts with 8, 9, a, or b.

Anatomy of a UUID v4

Breaking down 550e8400-e29b-41d4-a716-446655440000:

Segment	Bits	Meaning
550e8400	32 random	time_low (name is historical — fully random in v4)
e29b	16 random	time_mid (historical name — fully random in v4)
41d4	4 fixed + 12 random	Version nibble `4` (binary `0100`) + 12 random bits
a716	2 fixed + 14 random	Variant bits `10` (MSBs of first byte) + 14 random bits
446655440000	48 random	node (fully random in v4)

Note:The variant nibble at the start of the fourth group is always one of 8, 9, a, or b — because the high two bits of that byte are fixed to 10 (the RFC 4122 variant marker), leaving the remaining two bits free to vary.

UUID v4 vs Other Versions

RFC 4122 defines five UUID versions. Each solves a different problem:

UUID v1Timestamp + MAC

Combines a 60-bit timestamp (100-nanosecond intervals since Oct 1582) with the host MAC address. Monotonically increasing within a machine.

Use when: you need time-ordered IDs and don't mind leaking server identity and generation time.

UUID v3MD5 hash

Deterministic: same namespace + name always produces the same UUID. Uses MD5 hashing.

Use when: you need reproducible IDs from a known namespace (e.g. DNS names). Prefer v5 over v3.

UUID v4Random

122 bits of cryptographically secure randomness. No timestamp, no MAC, no namespace. The most common general-purpose choice.

Use when: you need unique IDs with no structural meaning and maximum privacy.

UUID v5SHA-1 hash

Like v3 but uses SHA-1. Still deterministic from namespace + name.

Use when: you need reproducible, content-addressed identifiers (e.g. stable IDs for resources identified by URL).

UUID v7Time-ordered random

Newer (RFC 9562, 2024). Encodes a Unix millisecond timestamp in the high bits, then random bits. Sortable and database-friendly.

Use when: you need database-index-friendly IDs with natural time ordering (prefer over v1 for new projects).

When to Use UUID v4

UUID v4 is the right tool in the vast majority of situations where you simply need "a unique ID" without additional constraints:

User and account IDs

Opaque user IDs that reveal nothing about account creation time or server identity. Cannot be enumerated or guessed.

Database primary keys

Works with any database engine. UUID v4 is safe to generate client-side and merge from distributed sources without coordination — no sequence table or central ID service required.

Session and token IDs

122 bits of randomness make brute-force guessing computationally infeasible — comparable in strength to a 122-bit random token.

File and object names

Deduplication-safe filenames for uploads, S3 object keys, or cache entries. No risk of two clients writing to the same key.

Idempotency keys

Generate a UUID on the client before submitting a request. The server can safely deduplicate retried requests without a shared counter.

Correlation and trace IDs

Attach a UUID to every log line and distributed trace span. No coordination needed across services or machines.

Note:If your use case requires sortable IDs (e.g. you want database rows to cluster by insertion time), consider UUID v7 instead. UUID v4 is intentionally random and will cause index fragmentation in B-tree indexes at high insert rates.

Collision Probability

With 122 random bits, the UUID v4 space contains 2¹²² ≈ 5.3 × 10³⁶ possible values. The probability of a collision follows the birthday problem:

UUIDs generatedCollision probability

1 billion (10⁹)~1 in 5.3 × 10¹⁸

1 trillion (10¹²)~1 in 5.3 × 10¹²

10¹⁸ (1 exabyte worth)~1 in 5,300

The commonly cited benchmark: to have a 50% chance of a single collision, you would need to generate approximately 2.71 × 10¹⁸ UUIDs. At a rate of 1 billion UUIDs per second, that would take roughly 85 years of continuous generation. For any real-world application, collisions are not a practical concern.

Code Examples

JavaScript — Browser and Node.js 14.17+

The crypto.randomUUID() method is available natively in all modern browsers (Chrome 92+, Firefox 95+, Safari 15.4+) and in Node.js 14.17+. No package installation required.

// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"

// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())

Node.js — older versions (uuid package)

const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

python

import uuid

# Generate a UUID v4
id = str(uuid.uuid4())
# → '110e8400-e29b-41d4-a716-446655440000'

# The uuid module uses os.urandom() — cryptographically secure
print(uuid.uuid4().hex)  # without hyphens
# → '110e8400e29b41d4a716446655440000'

Go

import "github.com/google/uuid"

id := uuid.New().String()
// → "110e8400-e29b-41d4-a716-446655440000"

// Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic)
// Always prefer github.com/google/uuid for production use

Rust

toml

# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }

rust

use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

Frequently Asked Questions

Is UUID v4 cryptographically secure?

UUID v4 itself is not a security primitive — it is an identifier format. However, when generated via crypto.randomUUID() (browser or Node.js) or equivalent OS-level APIs, the underlying entropy is cryptographically secure. This means UUID v4 values are suitable for use as session tokens or idempotency keys, where unpredictability matters. Do not use Math.random()-based UUID generators for security-sensitive contexts — only use APIs that explicitly draw from the OS CSPRNG.

Can two UUID v4s ever be equal?

Theoretically yes, but practically no. The probability of generating a duplicate within any realistic dataset (billions of IDs) is astronomically small — far less likely than a hardware fault causing data corruption. UUID v4 collision is treated as impossible in production system design. If you genuinely need a zero-collision guarantee, use a centralized counter or a database sequence instead.

UUID v4 vs nanoid — which should I use?

Both are random ID generators backed by a CSPRNG. The key differences:

UUID v4 follows the RFC 4122 standard, is recognized by every database and framework, and requires zero dependencies (native crypto.randomUUID()).
nanoid uses a URL-safe alphabet and is shorter by default (21 chars vs 36). Useful when URL length or readability matters. Requires an npm package.

Prefer UUID v4 when interoperability with external systems matters (APIs, databases, logging infrastructure). Prefer nanoid when you want shorter IDs and control the full stack.

Should I store UUIDs as strings or binary in databases?

For most databases, storing as a UUID or BINARY(16) column (16 bytes) is more efficient than a VARCHAR(36) string (36 bytes). PostgreSQL has a native uuid type. MySQL and MariaDB work well with BINARY(16) and the UUID_TO_BIN() / BIN_TO_UUID() helpers. SQLite users typically store as TEXT. The storage choice has no effect on uniqueness or correctness.

Why does UUID v4 have hyphens — and can I omit them?

Hyphens are part of the canonical UUID representation defined by RFC 4122. They are purely cosmetic — they carry no information and do not affect the 128-bit value. Omitting them gives you a compact 32-character hex string that is functionally equivalent. Most UUID parsers accept both forms. When in doubt, use the canonical hyphenated form for maximum compatibility with third-party tools and databases.

const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"

Language Guides

Generate UUID v4 in Python — uuid.uuid4()