Guides · Generation

UUID Generator Online: The Complete Guide

Learn how to generate UUIDs online, understand UUID v4 format, when to use UUIDs vs other ID types, and bulk generation for development.

Last updated: May 4, 2026

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier standardized in RFC 4122. It is represented as a 32-character hexadecimal string in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, typically written with hyphens separating the five groups: 550e8400-e29b-41d4-a716-446655440000.

UUIDs are designed to be globally unique without requiring a central coordination authority. This makes them ideal for distributed systems, microservices, and any situation where IDs need to be generated across multiple machines or services without collision risk.

UUID versions explained

v1
Time-based

Generated from the current timestamp and the MAC address of the generating machine. Contains encoded time, so UUIDs are sortable by creation time. Privacy concern: exposes MAC address.

v3
Name-based (MD5)

Deterministic UUID generated from a namespace UUID and a name string using MD5 hashing. Same inputs always produce the same UUID. Useful for content-addressed identifiers.

v4
Random

Generated from 122 bits of cryptographic randomness (plus 6 version/variant bits). No embedded time or machine info. The most widely used version for application-level IDs.

v5
Name-based (SHA-1)

Like v3 but uses SHA-1 instead of MD5. Preferred over v3 when deterministic UUIDs are needed.

v7
Time-ordered random

New in RFC 9562. Combines a millisecond-precision Unix timestamp prefix with random bits, making UUIDs both sortable and random. Ideal for database primary keys.

How to generate UUIDs online

Single UUID

Open the UUID Generator, click Generate, and copy the UUID. Each click produces a new random UUID v4 using the browser's crypto.randomUUID() function.

Bulk UUIDs

Set the count field to the number of UUIDs needed, click Generate, and copy all at once. Useful when seeding a database, populating a fixture file, or generating test IDs for a batch of records.

When to use UUIDs

Database primary keys

UUIDs are excellent primary keys for distributed databases or systems that create records across multiple services. Unlike auto-incrementing integers, UUID primary keys can be generated client-side before the database INSERT, enabling optimistic UI updates and event sourcing patterns.

API resources and external identifiers

Exposing sequential integer IDs in public APIs leaks record counts and enables enumeration attacks (an attacker can try IDs 1, 2, 3... to discover resources). UUIDs prevent enumeration by design.

Idempotency keys

Payment APIs (Stripe, PayPal) and message queues use idempotency keys to prevent duplicate processing. Generate a UUID per request and include it as the idempotency key to ensure safe retries.

File names and upload paths

When storing user-uploaded files, use a UUID as the filename (e.g. 550e8400-e29b.png) instead of the original name. This prevents path traversal attacks, naming conflicts, and leaking user information through file names.

Event IDs and correlation IDs

Distributed tracing systems use correlation IDs to track a request across multiple microservices. A UUID generated at the API gateway and propagated through all service calls enables end-to-end log correlation.

UUID v4 collision probability

UUID v4 uses 122 random bits (2¹²² ≈ 5.3 × 10³⁶ possible values). To have a 50% probability of a collision, you would need to generate approximately 2.71 × 10¹⁸ UUIDs — about 2.7 quintillion.

In practical terms: generating 1 trillion UUIDs per second for a million years still gives less than a 1-in-a-billion chance of any collision. UUID v4 collisions are a theoretical concern, not a practical one for any real application.

UUID vs ULID vs CUID vs NanoID

UUID v4

Universal standard, built into every platform and database. RFC 4122 compliant.

Not sortable, fragmented index inserts in B-tree databases, 36 characters with hyphens.

UUID v7

Sortable (time-ordered) + random. Great for database primary keys. RFC 9562 standard.

Less tooling support than v4, still 36 characters.

ULID

Lexicographically sortable, URL-safe, 26 characters. Monotonic within same millisecond.

Not a standard, less universal library support.

CUID2

Collision-resistant, URL-safe, shorter than UUID. Designed for web applications.

Not a standard, Node.js library required.

NanoID

Customizable size and alphabet, very compact (21 chars default). Cryptographically secure.

Not a standard, requires library. Custom alphabets need careful collision analysis.

Frequently asked questions

Is UUID the same as GUID?

Yes. GUID (Globally Unique Identifier) is Microsoft's term for the same 128-bit identifier standard. GUIDs and UUIDs are interchangeable in format and use. The term GUID is common in .NET and Windows; UUID is used everywhere else.

Should I store UUIDs as strings or binary in databases?

Binary (16 bytes) is more efficient for storage and indexed lookups. String storage (36 chars, or 32 without hyphens) is more portable and readable. PostgreSQL has a native uuid type (16 bytes). MySQL users often use BINARY(16) or VARCHAR(36). The PostgreSQL uuid type is the recommended option for new projects.

Do I need a library to generate UUIDs?

In modern environments, no. Browser JavaScript has crypto.randomUUID() built-in since Chrome 92, Firefox 95, and Safari 15.4. Node.js has it since v14.17. For older environments or UUID v7, the uuid npm package is the standard choice.

Are UUIDs safe to use as session tokens?

UUID v4 is cryptographically random but only 122 bits of entropy. For session tokens, 128+ bits of entropy is recommended. UUID v4 is acceptable, but dedicated secret generators that produce 256-bit random strings are preferable for high-security session tokens.

Can UUIDs be generated client-side safely?

Yes, for non-security identifiers. crypto.randomUUID() uses the OS CSPRNG and is safe for generating record IDs, correlation IDs, and idempotency keys in the browser. For security-sensitive tokens (session IDs, CSRF tokens), server-side generation is still recommended.