What Is a UUID? — Flassword guide

What Is a UUID? A Practical Guide for Developers

By the Flassword Team · ⏱️ Reading time: 6 min · 🟢 Beginner · Last updated July 13, 2026

Open the developer tools on almost any modern website or peek inside almost any database schema, and you'll run into a UUID sooner or later — a long string like 3fa85f64-5717-4562-b3fc-2c963f66afa6. Here's what that string actually represents, why it looks the way it does, and when it's the right choice over a simple counting number.

What is a UUID?

A UUID, or Universally Unique Identifier, is a 128-bit value conventionally written as 32 hexadecimal characters split into five groups by hyphens: 8-4-4-4-12. It's defined by an official standard, RFC 4122, so any system that follows the spec can generate and recognize them the same way, regardless of what programming language or database it's written in.

The point of a UUID is decentralization. A traditional auto-incrementing ID needs a single authority — usually a database — to hand out the next number in sequence, which becomes a bottleneck the moment more than one system needs to generate IDs independently. A UUID sidesteps that entirely: any device, anywhere, with no coordination and no network connection, can generate one that's virtually guaranteed not to collide with any other UUID ever generated, anywhere.

UUID versions explained

"UUID" isn't one single algorithm — it's a family of related formats, numbered by version, that all produce a 128-bit value in the same general shape but build it differently. The version number is actually encoded directly into the UUID itself, in one of the fixed bits mentioned above, so any system can tell at a glance which method produced a given identifier.

Version Built from Common today?
v1 Timestamp + network (MAC) address Rare — leaks creation time and hardware identity
v3 MD5 hash of a namespace and name Occasionally, for deterministic/repeatable IDs
v4 Random or pseudo-random bits Yes — the default choice almost everywhere
v5 SHA-1 hash of a namespace and name Occasionally, same use case as v3 with a stronger hash
v7 Timestamp + random bits (newer standard) Growing — sortable by creation time, unlike v4

Version 4 is what people mean by default when they just say "UUID," and it's what our UUID Generator produces — random bits, no embedded metadata, no coordination required.

UUID vs. auto-incrementing ID

Both are valid ways to identify a record; they just optimize for different things. An auto-incrementing integer (1, 2, 3…) is compact, sorts naturally by creation order, and is easy to read and type. A UUID is larger and harder to read at a glance, but it can be generated anywhere, by anyone, without ever checking in with a central counter — which matters enormously once you have more than one server or service creating records independently.

This is exactly why UUIDs are so common in distributed systems, microservices, and offline-capable apps: a mobile app can generate a UUID for a new record while offline, sync it later, and never worry about colliding with an ID some other device generated in the meantime. Try the same thing with auto-incrementing integers across two offline devices, and you'll eventually get two different records both claiming to be "row 47" the moment they try to sync back together.

How random is a v4 UUID, really?

Out of the 128 total bits, 6 are fixed by the specification itself — 4 bits mark the version, 2 bits mark the variant — leaving 122 bits of actual randomness. That works out to roughly 5.3 undecillion (5.3 × 1036) possible values. To put that in perspective, you could generate a billion UUIDs every second for the next hundred years and still have covered only an infinitesimal fraction of the total space.

That said, "random" is only as strong as the random number generator behind it. A properly implemented v4 UUID generator uses a cryptographically secure source — the same category of randomness covered in our password entropy guide — rather than a predictable pattern, which is what makes the uniqueness guarantee meaningful in practice rather than just in theory. A poorly implemented generator using a weak, seedable random function could theoretically produce predictable or repeating values, which is why it's worth confirming that whatever library or tool you use for UUID generation relies on your platform's cryptographic random source rather than a basic pseudo-random one.

Common use cases

  • Database primary keys, particularly in distributed or offline-first systems.
  • API request and session IDs, so a specific request can be traced through logs across multiple services.
  • File and object storage names, avoiding naming collisions without a central naming authority.
  • Test and seed data, where you need a large volume of guaranteed-unique placeholder identifiers quickly.
  • Idempotency keys for API requests, ensuring a retried request isn't accidentally processed twice.
Tip: Need a batch of UUIDs for seeding test data? Our generator can produce up to 20 at once, formatted with or without hyphens and in upper or lowercase, so they drop straight into whatever format your system expects, no manual reformatting required.

Frequently asked questions

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value, usually written as 32 hex characters split into five groups by hyphens, used to identify something without needing a central authority to hand out the next available number.

What's the difference between a UUID and a GUID?

Nothing meaningful — they're the same 128-bit structure. GUID (Globally Unique Identifier) is simply Microsoft's name for the concept defined by the UUID standard, RFC 4122, and the two terms are used interchangeably across the industry.

Is a UUID actually guaranteed to be unique?

Not mathematically guaranteed, but close enough for essentially any real-world purpose. A version 4 UUID has 122 random bits, around 5.3 undecillion possible values, so the realistic odds of ever generating a duplicate by chance are astronomically small.

Should I use UUIDs as database primary keys?

It's a common, well-supported choice, especially for distributed systems where multiple servers need to create records independently without coordinating. The tradeoff is that random UUIDs don't sort in creation order the way auto-incrementing integers do, and they take up more storage space.

Do UUIDs reveal any information about when or where they were created?

Version 4 UUIDs don't — they're built from random bits with no embedded timestamp or hardware identifier, which is exactly why they're the most commonly used version today. Older versions like v1 do embed a timestamp and network identifier, which is one reason they've fallen out of favor for public-facing systems.

Conclusion

A UUID is a simple idea with real practical weight behind it: a way to create a virtually-guaranteed-unique identifier without asking permission from anywhere else first. Version 4 — random bits, no metadata — covers the overwhelming majority of everyday use, from database keys to test data, and is exactly what a good UUID generator should default to. Whichever system you're building, reaching for a UUID is usually the simplest way to stop worrying about identifier collisions entirely.

Related articles

Free tools for this guide