How to Generate UUIDs Online: v4 vs v7 Explained
UUIDs give you globally unique identifiers without a central authority. This guide covers v4 vs v7, how the bits are structured, common pitfalls, and how to generate them in bulk privately in your browser.
Every distributed system eventually needs an identifier that no other process, server, or database can accidentally reuse. Auto-incrementing integers work fine on a single machine, but they fall apart the moment two services need to create records independently and merge them later. A universally unique identifier (UUID) solves that: 128 bits of structured data, generated without coordination, with collision odds so low they are treated as zero in practice.
This guide walks through what a UUID actually contains, why version 4 and version 7 behave so differently, and the mistakes that cause real bugs in production. You can follow along with the UUID Generator - a free tool that creates cryptographically random IDs entirely in your browser, one at a time or thousands at once.
What is a UUID, exactly?
A UUID (Universally Unique Identifier), also called a GUID, is a 128-bit value usually written as 32 hexadecimal digits split into five groups by hyphens: 8-4-4-4-12. Two of those bits and digits are not random at all - they encode the version (which algorithm produced the value) and the variant (which layout rules it follows). Everything else is either randomness or, for time-ordered versions, a timestamp.
The format is standardized in RFC 4122, recently superseded by RFC 9562, which is why every UUID library across every language produces interchangeable, identically-shaped output regardless of who generated it.
Why use a UUID instead of an auto-increment ID?
Sequential integer IDs are efficient but they leak information and require a single source of truth. If you expose /orders/1042 in a URL, a competitor can estimate your order volume by watching the counter climb. If two microservices each keep their own auto-increment counter, merging their data later means every foreign key collides and needs remapping.
- No central authority needed - any client, server, or offline device can mint an ID with zero coordination.
- Nothing to guess - a random UUID does not reveal how many records exist or when they were created.
- Safe to merge - records from different databases, shards, or offline caches can be combined without ID collisions.
- Works before a row exists - you can generate the ID client-side, before the record is even saved.
UUID v4 vs UUID v7
The UUID Generator supports the two versions developers reach for most today. Version 4 is pure randomness: 122 bits generated by a secure random source, with only the version and variant bits fixed by the spec. There is no way to infer creation order or timing from a v4 value - which is exactly the point when you want unpredictability.
Version 7 keeps that same unpredictability in most of the bits, but replaces the leading segment with a Unix millisecond timestamp. That means UUIDs generated later always sort after ones generated earlier, as plain strings. For anything backed by a B-tree index - most relational databases - that ordering matters a lot in practice.
Random v4 vs. time-ordered v7
Same entropy budget, different structure. Notice the v7 value's leading segment increases with time.
Input
Version: v4, then v7Output
v4: f47ac10b-58cc-4372-a567-0e02b2c3d479
v7: 017f22e2-79b0-7cc3-98c4-dc0c0c07398fWhich one should I default to?
If the ID is a database primary key, prefer v7 - the time-ordered prefix keeps new rows clustered together, which reduces index fragmentation and page splits compared to fully random v4 keys. For anything else, like a request ID or a one-off token, plain v4 is simpler and just as safe.
How the generator actually produces an ID
Under the hood, generating a UUID is a matter of filling 16 bytes with the right mix of randomness and fixed bits, then formatting them as hex. The critical detail is where those random bytes come from. Math.random() is a fast, non-cryptographic generator meant for animations and games - its output can, in principle, be predicted or biased. A proper UUID generator instead pulls from crypto.getRandomValues(), the Web Crypto API's cryptographically secure pseudo-random number generator, which is the same class of source used to generate encryption keys.
For v7, the timestamp portion comes from the system clock at generation time, encoded as milliseconds since the Unix epoch, with the remaining bits still filled from the secure random source. That combination is what gives v7 both ordering and unpredictability at once.
Nothing you generate ever leaves your browser
Because generating a UUID is pure local computation, the UUID Generator never sends a request to a server to create one - not for a single ID, and not for a bulk batch of thousands. That matters if you are pre-generating identifiers for records that reference customer data, internal API keys, or anything else you would rather not transmit anywhere.
Step-by-step: generate UUIDs in bulk
- Open the UUID Generator and choose a version - v4 for general-purpose randomness, v7 when the ID will be a sortable database key.
- Set the count. Leave it at one for a quick copy-paste value, or raise it to generate thousands of IDs in a single pass for seeding a database or test fixture.
- Adjust the format if your platform expects it: uppercase hex, hyphens stripped out, or each value wrapped in braces.
- Copy a single UUID with one click, or copy the entire newline-separated list to paste straight into a script, migration, or spreadsheet.
Regeneration is instant and unlimited - there is no rate limit or account requirement, since every ID is produced locally.
Common use cases for UUIDs
- Primary keys and foreign keys for database records, especially across services that write independently.
- Idempotency keys so a retried API request or queued message is not processed twice.
- Correlation IDs that tie related log lines together across a distributed trace.
- Unique filenames, upload paths, and cache keys that must never collide.
- Seeding realistic test fixtures and mock data during development.
- Temporary React keys or DOM element IDs while prototyping a UI.
Common mistakes when working with UUIDs
Rolling your own with Math.random()
A hand-written Math.random()-based generator can produce something that looks like a UUID but is not cryptographically unpredictable and may not even set the version/variant bits correctly. If uniqueness or unpredictability matters, use a generator built on crypto.getRandomValues, not a homemade string template.
Treating a UUID as if it were a secret
A v4 UUID is unguessable, but that does not make it a substitute for authentication. Anyone who obtains the value - through a leaked log, a referrer header, or a shared link - can use it. Use UUIDs to identify resources, not to authorize access to them.
Using v4 for a high-write primary key
Fully random v4 values scatter new rows across an index's key space, which increases page splits and hurts insert throughput at scale. If you are seeing that pattern on a busy table, switching new writes to v7 - which sorts by creation time - is usually a quick fix without changing your schema.
Sending the wrong format to a strict parser
Some libraries expect exactly 8-4-4-4-12 with lowercase hex and no braces; others accept uppercase or Microsoft-style {GUID} wrapping. If a downstream system rejects an otherwise-valid UUID, check its formatting requirements before assuming the value itself is bad.
Best practices for using UUIDs
- Default to v7 for new primary keys when your database and drivers support it, and v4 for everything else.
- Store UUIDs in a native
UUID/GUIDcolumn type where your database offers one - it is more compact and faster to index than storing them as plain text. - Generate IDs from a cryptographically secure source, never
Math.random()or a custom counter dressed up to look random. - Pair UUIDs with other identifier tools as needed - a Nanoid for shorter, URL-friendly slugs, or a hash when you need a deterministic ID derived from content rather than a random one.
- When debugging systems that use v7 keys, remember you can approximate a record's creation time just by looking at the ID - handy alongside a timestamp converter when comparing it to log timestamps.
Related tools
Create compact, URL-safe Nano IDs with a custom size and alphabet.
Compute SHA-1, SHA-256, SHA-384, and SHA-512 hashes of text or files.
Generate strong, random passwords with a live strength estimate.
Convert between Unix timestamps and human-readable dates, both ways.
Related guides
Nano ID packs UUID-level uniqueness into a shorter, URL-safe string. This guide covers how it works, how to size it correctly, and how to generate IDs without sending data to a server.
Cryptographic hashes let you fingerprint text or files and verify they haven't changed. Here's how SHA-1, SHA-256, SHA-384, and SHA-512 work, and how to compute them without uploading anything.
Reused and predictable passwords are the easiest way into an account. This guide explains what makes a password strong, how randomness and entropy work, and how to generate one safely without sending it anywhere.
Unix timestamps look simple until you hit a 13-digit number that breaks your date parser. This guide explains epoch time, common conversion mistakes, and how to convert timestamps to dates (and back) without uploading anything.