MT
My Toolbox

UUID Generator — Generate UUID v4 & v7 Online

Generate cryptographically random UUIDs instantly. Supports v4 (random) and v7 (time-sortable, RFC 9562). Generate one or bulk-generate up to 100. Uses crypto.randomUUID() — your browser does the work, nothing hits a server.

Generate unique UUIDs
Quickly generate unique identifiers

UUID v4 (Random)

Generated using random numbers. No structure, completely random. Suitable for most use cases.

UUID v7 (Time-based)

Generated using a timestamp and random numbers. Sortable by time, improving database performance.

UUIDs (Universally Unique Identifiers) are 128-bit numbers used to identify information in computer systems. The probability of generating two identical UUIDs is virtually zero.

UUID Versions Explained

A UUID is a 128-bit identifier formatted as 32 hex digits in 5 groups: 550e8400-e29b-41d4-a716-446655440000. The version number sits in the 13th character (the "4" in that example means v4).

UUID v4 is pure randomness — 122 random bits with 6 bits reserved for version and variant markers. The collision probability is astronomically low: you'd need to generate 2.71 × 10^18 UUIDs to have a 50% chance of one duplicate. In practice, that's "never."

UUID v7 (defined in RFC 9562, published 2024) is the new kid. It puts a Unix timestamp in the first 48 bits, followed by random bits. This means v7 UUIDs sort chronologically — huge win for database indexes. PostgreSQL and MySQL both suffer with random v4 UUIDs as primary keys because B-tree indexes fragment badly when inserts are random. v7 fixes this by making inserts always go to the end of the index.

When to use which: v4 for anything where ordering doesn't matter (session tokens, correlation IDs, idempotency keys). v7 for database primary keys, event IDs, or anything you'll sort by creation time. If you're starting a new project in 2024+, default to v7.

How to Use

  1. Select UUID version: v4 (random) or v7 (time-sortable).
  2. Set the count — 1 for a quick grab, up to 100 for bulk needs.
  3. Click Generate. Results appear instantly.
  4. Copy individual UUIDs or all at once. Lowercase with hyphens, ready to paste.

When You'll Use This

Database primary keys in distributed systems

Auto-increment IDs break when you have multiple write nodes. UUIDs let each node generate IDs independently with zero coordination. Use v7 if you need chronological ordering (most cases), v4 if you explicitly don't want IDs to reveal creation order.

API idempotency keys

Stripe, AWS, and most payment APIs require an idempotency key to prevent duplicate charges. Generate a v4 UUID per request — if the request fails and you retry with the same key, the server knows it's a retry, not a new charge.

File and object naming in cloud storage

Uploading user files to S3? Use a UUID as the object key. No collisions, no need to sanitize filenames, and no information leakage about upload order (with v4) or easy chronological listing (with v7).

Correlation IDs for distributed tracing

Generate a UUID at the entry point of a request, pass it through all microservices in headers. When something breaks, grep all logs for that UUID to see the full request path. v4 is ideal here — you don't need sorting, just uniqueness.

Things to Know

1.

v4 UUIDs are terrible as database primary keys (use v7)

Random v4 UUIDs cause B-tree index fragmentation because inserts land at random positions. This means more page splits, more disk I/O, and slower writes. Benchmarks show v7 UUIDs give 2-3x better insert performance in PostgreSQL. If you're already using v4, you can't easily migrate — but for new tables, use v7.

2.

UUIDs are not secrets

A UUID is an identifier, not a security token. v7 UUIDs leak creation time (the timestamp is right there in the first 48 bits). v4 UUIDs are random but only 122 bits of entropy — fine for uniqueness, not for security-sensitive tokens. For API keys or session tokens that need to resist brute-force, use 256-bit random values.

3.

Store as binary(16) in databases, not varchar(36)

A UUID as text is 36 characters (with hyphens). As binary, it's 16 bytes — less than half the storage. PostgreSQL has a native UUID type (16 bytes). MySQL's BINARY(16) with UUID_TO_BIN() works well. This matters when you have millions of rows with UUID foreign keys.

4.

Don't strip hyphens unless you have to

The standard format is 8-4-4-4-12 with hyphens. Some systems strip them (32 hex chars). Both are valid, but hyphens make UUIDs more readable and the version digit (position 13) easier to spot. Keep hyphens unless a system explicitly requires them removed.

Examples

UUID v4 — pure random

Note the "4" at position 13 (version) and 8/9/a/b at position 17 (variant).

Input

Version: v4

Output

f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v7 — time-sortable

Note the "7" at position 13. The first 12 hex chars encode the Unix timestamp in milliseconds.

Input

Version: v7

Output

018f6b2d-3c4a-7b12-9f8e-1a2b3c4d5e6f

Features

  • UUID v4: 122 bits of cryptographic randomness via crypto.randomUUID()
  • UUID v7: millisecond-precision timestamp + random bits (RFC 9562)
  • Bulk generation: up to 100 UUIDs in one click
  • Standard 8-4-4-4-12 format with lowercase hex
  • One-click copy for individual or all UUIDs
  • Runs 100% in your browser — zero network requests

Frequently Asked Questions

Will two UUIDs ever collide?

For v4: the probability is 1 in 2^122 (about 5.3 × 10^36). To put that in perspective, you'd need to generate 1 billion UUIDs per second for 85 years to reach a 50% collision probability. In any real system, it won't happen. For v7: even lower collision risk because the timestamp component ensures UUIDs generated at different milliseconds can never collide.

Should I use UUID v4 or v7 for my database?

v7, almost always. Random v4 UUIDs cause B-tree index fragmentation — inserts land at random positions, causing page splits and degrading write performance. v7 UUIDs are time-ordered, so inserts always append to the end of the index. PostgreSQL benchmarks show 2-3x better insert throughput with v7. The only reason to use v4 is if you explicitly need to hide creation order.

Can someone extract the timestamp from a UUID v7?

Yes. The first 48 bits of a v7 UUID are the Unix timestamp in milliseconds. It's not encrypted or hidden. If creation time is sensitive information in your use case, use v4 instead. For most applications (database IDs, event logs), exposing creation time is fine and actually useful.

UUID vs ULID vs nanoid — which should I use?

UUID v7 and ULID solve the same problem (time-sortable unique IDs) but UUID v7 is now an official RFC standard (9562). nanoid is shorter (21 chars vs 36) but not a standard — good for URL slugs, not for database PKs. If you need interoperability and standards compliance, use UUID v7. If you need short IDs for URLs, use nanoid.

How do I store UUIDs efficiently in a database?

Use the database's native UUID type if available (PostgreSQL has one, 16 bytes). In MySQL, use BINARY(16) with UUID_TO_BIN(uuid, 1) — the swap flag reorders bytes for better index performance with v1/v7. Never store as VARCHAR(36) in high-volume tables — it wastes storage and slows comparisons. With millions of rows, the difference is measurable.

Tips & Related Workflows