UUID Generator

Generate universally unique identifiers (UUIDs) online. Supports v4 (random), v1 (time-based), and bulk generation. Validate any UUID instantly.

UUID v4 — Randomly Generated

Generated using crypto.randomUUID() — cryptographically secure randomness.

UUID Validator

Paste any UUID to validate its format and detect its version.

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify information in computer systems. Standardised as RFC 4122, UUIDs are represented as 32 hexadecimal digits grouped by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx.

The M digit indicates the version (1–5) and N indicates the variant. v4 UUIDs use random data and are the most widely used type.

What is a UUID Generator?

A UUID (Universally Unique Identifier) generator produces 128-bit values used to uniquely identify information in computer systems without requiring a central registration authority — two independently generated UUIDs are, for all practical purposes, guaranteed to be unique even across billions of IDs generated at different times and on different machines. UUIDs are defined by RFC 4122 and formatted as 32 hexadecimal characters grouped in the pattern xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M indicates the UUID version and N indicates the variant. Version 4 UUIDs, the most widely used, consist of 122 random bits with only the version and variant bits fixed — the probability of generating two identical v4 UUIDs is approximately 1 in 5.3 × 10³⁶.

RFC 4122 defines five UUID versions with different generation methods. Version 1 uses the current timestamp combined with the generating machine's MAC address, making IDs time-ordered and machine-traceable — useful for distributed systems that need chronological ordering but problematic for privacy. Version 3 and Version 5 are name-based, generating a deterministic UUID from a namespace and name using MD5 (v3) or SHA-1 (v5) hashing — the same input always produces the same UUID, useful for content-addressable identifiers. Version 4 is purely random. Newer versions 6 and 7 (draft RFC 9562) introduce lexicographically sortable timestamp-based formats that combine the time-ordering benefits of v1 with the privacy safety of randomness.

UUID generators are used wherever unique identifiers are needed without coordination with a central authority: database primary keys for distributed systems that can't use auto-increment sequences across shards, API resource identifiers in RESTful services, session and CSRF tokens in web applications, file naming in content storage systems, distributed tracing correlation IDs, and event sourcing event IDs. The ability to generate a unique ID client-side or at the application layer — without a database round-trip to obtain an auto-incremented ID — is a significant architectural advantage in high-scale and microservices architectures.

How the UUID Generator Works

Formula, assumptions, and calculation steps for this dev tools tool.

Formula Used

UUID v4 uses 122 random bits formatted as 8-4-4-4-12 hex digits per RFC 4122

Methodology

Generates 122 bits of randomness and formats them into the standard 8-4-4-4-12 hexadecimal UUID pattern defined by RFC 4122.

Calculation Steps

Provide the input text or select generation options.
Apply the selected encoding, parsing, hashing, or formatting rule.
Validate the output where possible.
Return copy-ready developer output.

Assumptions and Limits

Generated or transformed output depends exactly on the supplied input.
Security-sensitive values should be handled carefully.
Browser tools do not replace production validation.

Frequently Asked Questions

What is the difference between UUID v1 and v4?

UUID v1 is generated from the current timestamp and the MAC address of the machine, making it time-ordered but potentially traceable. UUID v4 is entirely random (122 random bits), making it unpredictable and privacy-safe. v4 is recommended for most use cases.

Are UUID v4 values truly unique?

Yes, for all practical purposes. With 2^122 possible values (~5.3 × 10^36), the probability of generating two identical v4 UUIDs is astronomically small. You would need to generate about 2.7 × 10^18 UUIDs before having a 50% chance of a collision.

Can I use UUIDs as database primary keys?

Yes. UUIDs are commonly used as primary keys, especially in distributed systems where auto-increment integers would cause conflicts. The trade-off is slightly larger storage (16 bytes vs 4–8 bytes for integers) and reduced index locality for v4 UUIDs. UUID v7 (time-ordered random) is gaining popularity for databases.

What does nil UUID (all zeros) mean?

The nil UUID (00000000-0000-0000-0000-000000000000) is a special UUID with all 128 bits set to zero. It is typically used as a sentinel or placeholder value to represent the absence of a real UUID, similar to null in programming.

Real-World Applications

🗄️

Database Primary Keys in Distributed Systems

Traditional auto-increment integer primary keys require a database round-trip before an INSERT to obtain the next ID — a bottleneck in high-write distributed systems and impossible across database shards. UUIDs as primary keys allow the application (or client) to generate the ID before the INSERT, enabling optimistic writes, offline-first architectures, and conflict-free merging of records from multiple sources. UUID v7 (time-ordered) partially mitigates the random-insertion index fragmentation issue that affects UUID v4 in B-tree primary key indexes.

🔒

Session Tokens & CSRF Protection

Web frameworks generate UUID-based session identifiers and CSRF tokens because their 122 bits of randomness (UUID v4) make brute-force guessing cryptographically infeasible — an attacker would need to try 2^122 ≈ 5.3 × 10^36 values to guess a valid token. The UUID format also provides a human-readable 36-character string that can be stored in cookies and HTTP headers without additional encoding. UUID v4 is appropriate for session tokens; security-critical token generation should use a cryptographically secure random number generator.

📁

Content Storage & File Naming

Cloud storage systems (AWS S3, Google Cloud Storage, Azure Blob) and content management platforms use UUID v4 as object keys and file names — guaranteeing uniqueness across uploads without a central filename registry, preventing filename collision attacks (where a malicious actor uploads a file with the same name as an existing file), and enabling direct URL access to specific content objects. CDN-hosted assets with UUID names are effectively uncacheable-by-guessing, providing a simple form of access obfuscation.

🔍

Distributed System Tracing & Correlation

Microservices architectures generate a UUID-based trace ID at the entry point of each request and propagate it through all downstream service calls via HTTP headers (e.g. X-Request-ID, X-Trace-ID). Every log entry from every service includes the trace ID, enabling the complete request path across dozens of services to be reconstructed by filtering logs on a single UUID. OpenTelemetry, Jaeger, Zipkin, and Datadog all use UUID-based trace and span identifiers for this distributed tracing function.

📦

Event Sourcing & Message Queue IDs

Event-driven architectures using Kafka, RabbitMQ, or AWS SQS assign UUID identifiers to each event or message — enabling exactly-once processing (consumers record processed message UUIDs and skip re-deliveries), message deduplication, and reliable audit trails. In event sourcing systems, each domain event carries a UUID that provides permanent, addressable identity to every state change in the system history, supporting replay, projection rebuilding, and temporal queries.

🧪

Test Data Generation & API Mock Development

Developers writing unit tests, integration tests, and API mock servers use UUID generators to produce realistic-looking entity IDs for test fixtures — ensuring test data uses ID formats that match production (preventing "works in tests, fails in production" bugs caused by tests using integer IDs when production uses UUIDs). API mock tools like Postman and WireMock generate UUID values in responses to simulate realistic production API behaviour during frontend and integration testing.

Common Mistakes

Using UUID v1 in contexts requiring privacy — it embeds your MAC address

UUID v1 encodes the MAC address of the generating machine in the lower 48 bits. Any UUID v1 generated on the same machine shares the same MAC address component, allowing linkage of records even across different tables, applications, or time periods. This was famously exploited to identify the author of the Melissa virus in 1999. Never use UUID v1 for user-facing identifiers, session tokens, or any context where the generating machine's identity should not be disclosed. Use UUID v4 (random) instead.

Storing UUIDs as VARCHAR(36) instead of BINARY(16)

A UUID stored as the 36-character hyphenated string "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" in a VARCHAR(36) column occupies 36 bytes. The same UUID stored as raw binary in a BINARY(16) column occupies 16 bytes — 55% smaller. For tables with millions of rows and UUID primary keys and foreign keys, the difference is significant in storage and especially in index performance. Database ORMs can transparently store UUIDs as BINARY(16) while exposing them as formatted strings to the application layer.

Treating UUID v4 as a security-quality cryptographic token without verifying RNG quality

UUID v4 is only as random as the underlying random number generator (RNG). In environments with poor entropy (early-boot virtual machines, some embedded systems, containers with limited entropy sources), the RNG may produce predictable values that undermine UUID unpredictability. For session tokens, CSRF tokens, and password reset tokens, use a cryptographically secure pseudorandom number generator (CSPRNG) explicitly: crypto.randomUUID() in browsers/Node.js, secrets.token_hex() in Python, SecureRandom in Java — not a generic UUID library that may use a non-CSPRNG.

Using sequential UUIDs as primary keys without considering index fragmentation

UUID v4 keys are random, so sequential INSERTs produce randomly ordered primary key values. In a B-tree index (used by most relational databases for primary keys), random insertions cause frequent page splits and fragmentation, degrading write performance and increasing storage overhead at scale. UUID v6 and v7 (time-ordered, lexicographically sortable) were designed specifically to address this — they maintain time ordering in the high bits so sequential inserts produce approximately sequential index entries, behaving similarly to auto-increment keys from an index efficiency perspective.

Conflating UUID "uniqueness" with cryptographic security

UUID v4 has 122 bits of randomness and a collision probability of approximately 1 in 10^36 per pair — effectively collision-proof for any practical application. However, "collision-proof" is not the same as "unguessable." An attacker who can observe a list of valid UUID v4 values does not gain meaningful information that helps predict the next one (due to the RNG), but an attacker who knows the UUID format and has a weak RNG may be able to narrow the search space. For tokens requiring forward secrecy or resistance to offline brute-force attacks, use dedicated CSPRNG-based token generation rather than relying on UUID formatting conventions.

UUID Versions Quick Reference

Version	Generation Method	Best Use
v1	Timestamp + MAC address	Time-ordered; avoid for user-facing IDs
v3	MD5 hash (namespace + name)	Deterministic, name-based IDs
v4	Random (122 bits)	Most common; session IDs, database PKs
v5	SHA-1 hash (namespace + name)	Deterministic, name-based IDs
v7	Unix timestamp + random	Sortable; best for DB primary keys

References

Leach, P. et al. RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. IETF, 2005.
Davis, K. et al. RFC 9562: Universally Unique IDentifiers (UUIDs). IETF, 2024.
NIST. SP 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators. nist.gov, 2015.
Percona. UUID vs Auto-Increment: Primary Key Comparison. percona.com, 2023.
ISO/IEC 9834-8. Procedures for the operation of OSI Registration Authorities: Generation and registration of UUIDs. iso.org, 2014.