UUID Generator Online: Everything You Need to Know About UUIDs, GUIDs, v4 and v7
If you have ever built a database-backed application, integrated a third-party API, or distributed configuration across a fleet of servers, you have almost certainly met the 36-character string that looks like 550e8400-e29b-41d4-a716-446655440000. That string is a UUID — a Universally Unique Identifier — and it is one of the quiet workhorses of modern software. This guide explains what UUIDs are, how the different versions work, when to pick version 4 versus the newer time-ordered version 7, how to validate them, and what the terms GUID, nil UUID, variant and canonical form actually mean. Along the way you can use the free UuidMint generator above to mint fresh identifiers, bulk-produce thousands of them, and inspect any UUID you paste in.
What is a UUID?
A UUID is a 128-bit value — sixteen bytes — rendered as 32 hexadecimal digits arranged in five groups separated by hyphens: 8-4-4-4-12. The format was first standardized by the Open Software Foundation in the 1990s, carried forward by RFC 4122, and modernized in 2024 by RFC 9562, which is the current authoritative specification. The defining property of a UUID is right there in the name: it is meant to be universally unique. Two different systems, on opposite sides of the planet, with no communication between them, can each mint UUIDs and the probability that they ever mint the same one is so small that engineers simply ignore it.
That uniqueness-without-coordination property is the whole point. In the early days of computing, unique identifiers usually came from a single source of truth: an auto-incrementing integer column in a central database, a ticket server handing out serial numbers, a master process that everyone asked. That works until you have distributed systems — microservices in different regions, offline-first mobile apps that sync later, event streams processed by dozens of consumers. Coordinating a single counter across all of them is expensive and fragile. UUIDs flip the model: instead of guaranteeing uniqueness by asking permission, you guarantee it with mathematics. Pick 122 random bits (for version 4), and the space of possible values — roughly 5.3 × 1036 — is so vast that accidental collisions do not happen in the lifetime of the universe, let alone your project.
UUID versions: v1 through v8
The word "version" in UUID-land does not mean "the latest release of the standard". It means the generation method, encoded as a four-bit nibble in a fixed position (the first character of the third group — look at the 4 in 550e8400-e29b-41d4-a716-446655440000). RFC 9562 defines eight versions. Version 1 encodes a timestamp plus a hardware (MAC) address; it is largely obsolete now because it leaks machine identity and is bad for privacy. Version 2 is a niche DCE variant rarely seen in the wild. Versions 3 and 5 are deterministic: feed a namespace UUID plus a name into MD5 (v3) or SHA-1 (v5) and you always get the same UUID back — useful when you need a stable identifier derived from existing data, such as hashing a URL into an ID column.
Version 4 is the one most developers mean when they say "generate a UUID": 122 bits of cryptographic randomness with the version nibble set to 4 and the two variant bits set to 10. It is simple, private (no timestamp, no MAC address), and safe. Version 6 is a field-reordered variant of v1 that keeps timestamp bits in sortable order, mostly of interest to systems migrating away from v1. Version 7 is the modern answer to "I want a UUID that also sorts by creation time", and it deserves its own section. Version 8 is an escape hatch: the version and variant bits are fixed, but every other bit is application-defined, for specialized systems that want to embed things like tenant or shard identifiers inside a UUID-shaped column.
UUID v7: the time-ordered upgrade
UUID v7 was added by RFC 9562 in 2024 and is rapidly becoming the default choice for database primary keys. Its bit layout is elegant: the first 48 bits are the Unix timestamp in milliseconds, big-endian; then the version nibble 7; then 12 random bits; then the two variant bits; then 62 more random bits. Because the timestamp occupies the most significant bits, v7 UUIDs sort in chronological order when compared as plain strings. A v7 minted at noon sorts before one minted at 12:01 — no parsing required.
Why does that matter? Database indexes are trees, and inserting random keys into a tree (which is what v4 gives you) causes page splits, fragmentation, and slower inserts as the table grows. Inserting monotonically increasing keys — like v7, or classic auto-increment integers — keeps new rows clustered at the "end" of the index. Teams at companies running large PostgreSQL and MySQL fleets report meaningful insert-performance improvements after switching primary keys from v4 to v7, while keeping every benefit of decentralized ID generation. The 74 random bits per millisecond of entropy still make collisions and enumeration practically impossible, so v7 is not meaningfully more predictable than v4 for security purposes. Try the sort-order demo above to see the difference yourself: it mints both types, shuffles them, sorts the strings, and shows the v7 list snapping back into exact creation order.
One more v7 trick that developers love: because the timestamp is embedded in the first 48 bits, you can read the creation time straight out of the identifier. UuidMint's validator does exactly this — paste any v7 UUID and it decodes and displays the UTC timestamp it was minted at, down to the millisecond. This is handy for debugging ("when was this record created, roughly?"), for log correlation, and for building time-range queries directly on ID columns.
GUID vs UUID: is there a difference?
Functionally, no. GUID — Globally Unique Identifier — is Microsoft's term for the same 128-bit identifier, used across Windows, .NET (Guid.NewGuid()), SQL Server's uniqueidentifier type, and COM. A GUID minted by .NET is a perfectly valid RFC 9562 UUID and vice versa; the bits are the same. The differences are purely conventional: GUIDs are usually displayed in uppercase and wrapped in braces, like {550E8400-E29B-41D4-A716-446655440000}, while the RFC canonical form is lowercase without braces. That is why UuidMint ships GUID presets — one click gives you the uppercase, braced, or hyphen-free rendering your platform expects, without regenerating the underlying identifier.
Anatomy of a UUID: version, variant, nil
Three concepts show up in every validator, including the one on this page, so it is worth understanding them precisely. The version is the four-bit nibble at the start of the third group (character 15 in the canonical string, counting from 1). It tells you how the UUID was made: 4 means random, 7 means time-ordered, and so on. The variant is encoded in the top bits of the byte that begins the fourth group: the two-bit pattern 10 (hex digits 8, 9, a, or b in that position) means the UUID follows the RFC 9562 layout; patterns starting with 0 indicate the old Apollo NCS format, and 11 indicates the Microsoft-reserved variant. Almost everything you encounter in practice is the RFC variant.
The nil UUID — 00000000-0000-0000-0000-000000000000 — is the all-zeros special case. It is not random and not time-ordered; it is a sentinel meaning "no UUID here", used as a default value, a placeholder in test fixtures, or an explicit null in APIs that pass UUIDs around. A good validator flags it separately from genuinely invalid input, because "all zeros" is meaningful data in many systems, not a typo. (RFC 9562 also defines its mirror image, the max UUID with all bits set, used for range-query boundaries.)
Validating UUIDs: what a validator checks
Paste a string into any UUID validator and it performs several checks in sequence. First, the shape: 32 hex digits in the 8-4-4-4-12 grouping, optionally accepting the compact 32-digit form, surrounding braces or parentheses, and either letter case. Second, the version nibble: is it a defined version (1–8)? Third, the variant bits: do they indicate a recognized layout? Fourth, special values: is it the nil UUID? A strict validator will reject strings with non-hex characters, wrong group lengths, missing hyphens in odd places, or version digits like 0 or 9 that do not correspond to any defined generation method. UuidMint's validator goes one step further and decodes the v7 timestamp when one is present, turning a bare identifier into a small forensic report.
Common UUID use cases
Primary keys are the classic use case, and v7 has made them interesting again. Beyond that, UUIDs show up as session and API tokens, idempotency keys (send the same UUID with a retried request and the server knows it is a duplicate), distributed trace and correlation IDs that follow a request across microservices, filenames for user uploads (unguessable, collision-free), feature-flag and experiment identifiers, and seed data for tests and load benchmarks — which is where bulk generation with a dedupe check earns its keep. If you seed a test database with ten thousand v4 UUIDs, the mathematical chance of a duplicate is negligible, but running the automatic dedupe report costs nothing and turns "trust me" into "verified".
Collision math and entropy
The numbers are worth internalizing because they explain why UUIDs are trusted at planetary scale. A version 4 UUID has 122 random bits: 2122, or about 5.3 × 1036 possible values. If you generated one billion UUIDs every second, you would need roughly a hundred years to reach even a 50% chance of one collision. Version 7 keeps 74 random bits per millisecond timestamp — 274 possibilities per millisecond — which is still so large that same-millisecond collisions do not occur outside of adversarial construction. The practical takeaway: use crypto.getRandomValues (which UuidMint uses exclusively — never Math.random) as your randomness source, and uniqueness takes care of itself.
Formats, casing and storage tips
The canonical text form is lowercase with hyphens, and most systems accept it case-insensitively — but not all. SQL Server's uniqueidentifier is forgiving; some NoSQL drivers and URL routers are pickier. A few practical rules: normalize to one case on ingest (lowercase is the RFC recommendation); strip braces before storing; store as a native UUID/binary(16) type in the database when available rather than as text, to save space and keep index comparisons fast; and never use a UUID as a security token by itself unless it was generated with a cryptographic RNG and is long enough to resist guessing — v4 qualifies, but pair it with proper authentication anyway. When an API demands no hyphens (32 continuous hex) or uppercase braced GUIDs, use the preset buttons above rather than hand-editing — hand-editing is exactly how invalid UUIDs are born.
Why UuidMint?
Plenty of sites generate a single random UUID. UuidMint was built for the workflows developers actually have: minting time-ordered v7 identifiers for new database tables, producing thousands of seed IDs with a uniqueness report you can screenshot into a test plan, pasting a suspicious ID from a log and learning its version, variant and creation time in one glance, and copying GUID-style presets without retyping. Everything runs in your browser with the Web Crypto API — nothing is sent to any server — and there is no signup, no paywall and no watermark. Whether you searched for a uuid generator online, a guid generator, a uuid v4 generator, a uuid validator, or a way to generate uuid v7, you are in the right place: mint away.
Frequently Asked Questions
What is a UUID and how is it generated?
A UUID (Universally Unique Identifier) is a 128-bit label written as 32 hexadecimal digits in five hyphen-separated groups. Version 4, the most common type, is generated from a cryptographically secure random number generator with the version and variant bits fixed per RFC 9562, giving 122 random bits and a effectively-zero collision chance.
What is the difference between UUID v4 and UUID v7?
UUID v4 is fully random. UUID v7 starts with a 48-bit Unix millisecond timestamp followed by the version nibble 7 and 74 random bits, so v7 UUIDs sort in chronological order. That makes v7 the better choice for database primary keys (better index locality), while v4 remains perfect for opaque tokens and general-purpose IDs.
How do I validate a UUID string?
Paste it into UuidMint's Validator tab. It checks the 8-4-4-4-12 hex shape (accepting braced, uppercase and 32-hex compact forms), reports the version and variant, flags the nil UUID, and decodes the embedded timestamp for v7 UUIDs.
What is the nil UUID?
The nil UUID is 00000000-0000-0000-0000-000000000000 — all bits zero. It is a sentinel meaning "no value" used as a placeholder in databases, APIs and test fixtures. UuidMint's validator identifies it explicitly so you can distinguish it from malformed input.
Are GUIDs and UUIDs the same thing?
Effectively yes. GUID is Microsoft's name for the same 128-bit identifier. The only practical difference is formatting: GUIDs are conventionally uppercase and wrapped in braces, e.g. {550E8400-E29B-41D4-A716-446655440000}. UuidMint's presets produce exactly these styles.
Can two generated UUIDs ever collide?
In practice, no. A v4 UUID has 122 random bits — about 5.3 × 10³⁶ possible values. Even at a billion UUIDs per second you would need over a century to reach a 1% collision chance. UuidMint's bulk mode still runs an automatic dedupe check on every batch so you can verify uniqueness directly.