Generate UUID v1, v4, v5, and v7 identifiers in bulk (up to 100 at once). Choose uppercase or lowercase, with or without hyphens, or generate the Nil UUID.
Fully random
A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier) in Microsoft ecosystems, is a 128-bit identifier formatted as a 36-character string of hexadecimal digits arranged in five groups separated by hyphens, like 550e8400-e29b-41d4-a716-446655440000. It's designed to be generated independently, by different systems, in different locations, at different times, without any central coordinating authority — and still be, for all practical purposes, guaranteed unique.
UUIDs are standardized in RFC 9562 (which superseded RFC 4122), and are used everywhere unique identification matters without relying on an auto-incrementing counter from a single database: primary keys in distributed databases, session tokens, API request IDs for tracing and logging, device identifiers, and object references in countless software systems. Unlike a simple incrementing integer ID, a UUID doesn't reveal how many records exist or in what order they were created (except for the newer time-ordered versions, which deliberately expose creation order as a feature), and can be generated safely offline or across multiple servers without any risk of collision.
UUID v1 combines the current timestamp (to 100-nanosecond precision) with a 'node' identifier, historically the computer's MAC address, though modern implementations (including this tool) typically substitute a random number for privacy, since embedding a real MAC address can leak information about the machine that generated the ID. v4 is the simplest and most widely used version: 122 bits of cryptographically random data, with no embedded information whatsoever — just pure randomness, which is why it's the default choice for most general-purpose use cases.
v5 is deterministic rather than random: it's a SHA-1 hash of a namespace UUID plus a name string you provide, meaning the exact same namespace and name will always produce the exact same UUID, every time, on any system — useful when you need a stable, reproducible ID derived from existing data rather than a random one. v7, the newest version (standardized in 2024), combines a Unix millisecond timestamp with random bits, similar in spirit to v1 but using a modern timestamp format and no node identifier — its key advantage is that v7 UUIDs sort chronologically by creation time, which dramatically improves database index performance compared to the effectively-random ordering of v4.
UUIDs solve a specific coordination problem: generating unique identifiers across multiple systems, servers, or offline clients without needing to check with a central authority first. Distributed databases use UUIDs as primary keys specifically because multiple database nodes can generate IDs independently and merge their data later without any risk of two records accidentally sharing the same ID — something an auto-incrementing integer can't safely do across multiple write nodes. API design commonly uses UUIDs for request IDs and trace IDs, since they let you correlate a single request across dozens of microservices in a distributed system's logs without any service needing to coordinate ID generation with the others.
Other common uses include session tokens and API keys, object storage keys (like S3 bucket file names), device and installation identifiers for analytics, feature flag and A/B test bucketing, and idempotency keys that let a client safely retry a failed API request without accidentally processing it twice. Anywhere you need an identifier that's guaranteed unique without a central sequence generator, a UUID is almost always the right default choice.
Not with mathematical certainty, but close enough that collisions are considered a non-issue in virtually every real-world scenario. A v4 UUID has 122 bits of randomness, giving roughly 5.3 × 10³⁶ possible values — to put that in perspective, you'd need to generate around 1 billion UUIDs per second for about 85 years before there's just a 50% chance of a single collision occurring anywhere in that entire set, a scenario so far beyond any realistic application's actual UUID generation volume that it's treated as effectively impossible in practice.
The 'universally unique' guarantee is therefore probabilistic, not absolute — but the probability is so astronomically small that essentially every major database, cloud platform, and software system treats UUID collisions as a non-concern. The one caveat worth knowing: v5's uniqueness depends entirely on your namespace-plus-name combination being unique, since it's deterministic rather than random — generate v5 UUIDs from duplicate namespace/name pairs and you will, correctly and predictably, get duplicate UUIDs back, which is the expected behavior, not a flaw.
UUID Generator covers one kind of identifier. These related developer tools handle passwords, hashes, and encoded tokens you'll often need alongside unique IDs.