UUID v4 Generator

What is a UUID and when should you generate one?

When to use

1. 01

   Primary key in database tables where multiple services insert data — UUID eliminates the need for centralized sequence coordination.

2. 02

   Request ID in distributed logs — attaching a UUID to each request enables tracing the user's journey across microservices.

3. 03

   Idempotency key in payment APIs — using a client-generated UUID prevents double-charging on retry.

4. 04

   Upload identifier in S3 — UUID in the filename prevents collision and reveals nothing about internal structure.

5. 05

   Invite or password-recovery token — UUID v4 works as a random token secure enough for these use cases.

How calculation works

Frequently asked questions

Which UUID version should I use?

Modern default is UUID v7 (RFC 9562) — combines temporal order (good for database indexes) with enough randomness for uniqueness. UUID v4 is still fine for cases where order doesn't matter. UUID v1 is rarely the best choice today — it exposes MAC and generation time. UUID v3/v5 are deterministic (hash of namespace + name) — useful for generating the same UUID from the same input.

Is UUID collision possible?

Theoretically yes, practically no. Collision probability of two randomly generated v4 UUIDs in all of human history is on the order of 2^-122 — equivalent to winning the lottery multiple times in a row. For UUID v1 and v7 (which use timestamps), probability is even lower, since timestamps add temporal uniqueness.

Is UUID secure as an authentication token?

UUID v4 with 128 random bits is strong enough for short-lived tokens (invite, password reset) — entropy equivalent to 122 random bits. For long-lived tokens (API key, JWT), also use periodic rotation, expiration, and revocation. Never use UUID v1 or v3 as a token — they can be predicted/derived.

Why can UUID in databases be slow?

Because UUID v4 is random — inserts in a B-tree index cause fragmentation and cache misses. UUID v7 (timestamp-ordered) solves this: inserts become append-only in the index, performance similar to auto-increment integers. Postgres has native support via uuidv7() in recent versions.

Can I shorten UUID for URLs?

Yes, by encoding the 128 bits in Base62 or Base64URL (not standard Base64, which has problematic characters in URLs). Tools like NanoID and Sqids do this by default, producing 21-character IDs with the same entropy. But if you already have a generated UUID, keeping the canonical 36-character format is more portable.

Does UUID v4 work offline?

Yes — UUID v4 generation requires no central coordination or internet, just a cryptographic random number generator. This is what makes UUIDs valuable in distributed systems: an offline client can generate a valid ID and sync later without collision risk.

Related tools

• JSON Formatter

  Structure payloads
• Hash Generator

  Deterministic fingerprints
• Slug Generator

  User-friendly URLs

Official sources

Tabelas, leis e referências consultadas para fundamentar esta ferramenta.

1. 01

   International standard·RFC 4122 (2005)·IETF · Internet Engineering Task Force

   RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace

   Specification for UUID identifiers (versions 1, 3, 4, and 5), canonical 36-character format, and generation rules to ensure global uniqueness.

   Consultar fonte oficial
2. 02

   International standard·RFC 9562 (2024)·IETF · Internet Engineering Task Force

   RFC 9562 — Universally Unique IDentifiers (UUIDs)

   Update to the UUID standard with versions 6, 7, and 8 — time-ordered and optimized for use in databases and modern distributed systems.

   Consultar fonte oficial