A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier), is a 128-bit identifier formatted as 32 hexadecimal digits in five groups separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. The total number of possible UUIDs is 2^122 - so large that collisions are practically impossible.

What is the difference between UUID v1, v3, v4, and v5?

UUID v1 is generated from the current time and the machine's MAC address. UUID v3 and v5 are deterministic - they generate a UUID from a namespace and a name using hash functions. UUID v4 is randomly generated. v4 is by far the most commonly used because it requires no coordination, has no privacy concerns (unlike v1 which embeds MAC addresses), and is truly random.

Are these UUIDs truly unique?

UUID v4 uses cryptographically secure random numbers (via the Web Crypto API). The probability of generating two identical UUIDs is astronomically small - roughly 1 in 5.3 × 10^36. For practical purposes, they are unique. You would need to generate roughly a billion UUIDs per second for about 85 years to have a 50% chance of a single collision.

When should I use UUIDs?

UUIDs are ideal as database primary keys (especially in distributed systems where multiple servers generate records independently), session identifiers, file names for uploaded files, API resource identifiers, and anywhere you need a unique ID that does not reveal sequential information.

Should I store UUIDs as strings or binary in my database?

Binary (16 bytes) is more efficient for storage and indexing than the string form (36 characters). Most databases have a native UUID type (PostgreSQL, MySQL 8+) that stores them efficiently. For databases without a UUID type, store as BINARY(16) or CHAR(36). The string format is best for human-readable contexts like URLs and logs.

Is UUID generation done on the server?

No. UUID generation runs entirely in your browser using the Web Crypto API (crypto.randomUUID()). No data is sent to any server, and each UUID is generated fresh on your device.

UUID Generator

Generate random UUIDs (v4) online. Free UUID generator - create one or bulk generate unique identifiers instantly.

🔒 Your text stays in your browser - nothing is sent to our servers

Count:

Custom:

Uppercase

Generated UUIDs

How to Use

Three steps to get started

Choose how many

Use the count selector to choose how many UUIDs you want - from 1 up to 100.

Click Generate

Click "Generate UUIDs" to instantly create cryptographically random UUID v4 identifiers.

Copy all

Click "Copy All" to copy all generated UUIDs to your clipboard, one per line.

About This Tool

UUID v4 generation explained

UUID (Universally Unique Identifier) is a standardized 128-bit identifier defined in RFC 4122. Its canonical string form looks like this: 550e8400-e29b-41d4-a716-446655440000

The 36-character string is 32 hex digits in a fixed 8-4-4-4-12 grouping. Not all of those bits are random: 4 bits encode the version (the 4 that always appears at the start of the third group) and 2 bits encode the variant (which is why the fourth group always begins with 8, 9, a, or b). That leaves 122 random bits. This tool draws them from crypto.randomUUID(), backed by the Web Crypto CSPRNG rather than Math.random(), so the output is suitable for identifiers that must be unguessable as well as unique.

Common use cases for UUIDs:

Database primary keys: Generate IDs on the client before inserting, enabling optimistic UI
Distributed systems: Multiple services can generate IDs independently without coordination
File names: Prevent filename collisions for uploaded files
Idempotency keys: Deduplicate retried API requests safely - Stripe and most payment APIs expect one per request
Correlation and trace IDs: Stitch a single request together across microservice logs
Public-facing identifiers: Avoid leaking record counts the way sequential integers do

Which UUID version should you use?

RFC 9562, published in 2024, updates the original RFC 4122 and adds three new versions. v1 encodes a timestamp plus the machine's MAC address - sortable, but it leaks hardware identity. v3 and v5 are deterministic hashes of a namespace and a name (MD5 and SHA-1 respectively), which makes them the right choice when the same input must always yield the same ID. v4 is pure randomness and remains the default for almost everything. v7 is the notable newcomer: it puts a 48-bit Unix millisecond timestamp in the high bits, so v7 UUIDs sort chronologically while staying collision-resistant. If you are choosing a primary key today, v7 is worth evaluating against v4.

That sortability question is not academic. Random v4 keys scatter inserts across a B-tree index, causing page splits and cache churn that shows up as write amplification on large tables - the reason Postgres and MySQL teams often reach for v7, ULIDs, or Snowflake IDs instead. Storage matters too: as CHAR(36) a UUID costs 36 bytes, versus 16 as a native uuid or BINARY(16) column.

One caveat: a UUID is unique, not secret by policy. v4 values are unguessable, but v1 and v7 embed timestamps, so never treat a UUID as an authorization token on its own. The uppercase toggle covers legacy systems (notably Microsoft GUID tooling) that expect capitals; RFC 9562 specifies lowercase on output while requiring parsers to accept both. Every identifier here is produced inside your browser - nothing is requested from a server, nothing is recorded, and closing the tab is the only cleanup needed.

FAQ

Frequently Asked Questions

Related Tools