How to Generate a UUID: v4 vs v1, the Anatomy, and When Each Version Fits

Every database row, API request and uploaded file that must never be confused with another one needs an identifier, and the moment two independent systems create records without talking to each other, a simple counting number stops working. That is the problem a UUID solves. A UUID — a universally unique identifier — is a 128-bit label written as 32 hexadecimal characters in five groups, in the 8-4-4-4-12 pattern, standardised in RFC 9562 and designed so that identifiers generated independently, on different machines, by different people, at different times, are practically guaranteed never to collide. Our free UUID generator creates version 4 (random) or version 1 (time-based) UUIDs right in your browser: generate 1 to 100 at a time, copy them one by one or all at once, and paste them straight into your database, API or code. Nothing is sent to a server, nothing is logged, and there is no sign-up. This guide explains how to use it, how to read a UUID at a glance, when to choose each version, and the mistakes that turn a good identifier into a privacy or security problem.

How to Use the UUID Generator

1. Choose a version. Version 4 (random) is the default and the right choice for almost everything: database keys, API request ids, session tokens and test fixtures. Pick version 1 (time-based) when you want identifiers that sort in creation order — for example, as a primary key on a very large table where index performance matters. 2. Set how many you need (1–100). Five is the default. Need a batch of test users? Ask for 100. Need a single idempotency key for a payment request? Set it to 1. 3. Press Generate UUIDs. A fresh batch appears instantly, in 8-4-4-4-12 format, ready to use. 4. Copy. Each line has its own Copy button, or hit Copy All to grab the whole batch as a newline-separated list — handy for pasting into a SQL INSERT, a seed script or a spreadsheet column. 5. Regenerate any time. Switching the version dropdown re-generates the list automatically, so comparing v1 and v4 output is a one-click affair. Because generation happens entirely in your browser with the Web Crypto API, there is no queue, no rate limit and no round trip to a server. It works offline once the page has loaded, and it works identically in every modern browser. The tool uses crypto.randomUUID() and crypto.getRandomValues(), the browser's cryptographically secure random number generator — the same source of randomness password managers and TLS rely on — so the random parts of your UUIDs are genuinely unpredictable, not the output of a weak Math.random() call.

What a UUID Looks Like: The Anatomy

A UUID is a 128-bit number, usually written as 32 lowercase hexadecimal characters split into five groups by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The two letters that are not x's carry the metadata. M is the version digit — the 13th hex character — and it is always 1 for a time-based UUID or 4 for a random one. N is the variant field — the 17th hex character — and in every standards-compliant (RFC 9562) UUID it is one of 8, 9, a or b. That is the fastest way to eyeball a UUID: if the 13th character is a 4 and the 17th is an 8–b, you are looking at a valid v4. Here is a real v4 UUID generated by this tool, with its anatomy labelled: f47ac10b-58cc-4372-a567-0e02b2c3d479. The full string is 32 hex characters in 8-4-4-4-12 groups. The version digit, the 13th character, is 4, so this is version 4, random. The variant digit, the 17th character, is a, which sits inside 8–b, so this is the RFC 9562 variant. The remaining 30 hex digits are 122 random bits — about 5.3 × 10³⁶ possibilities — which is why collisions are, for every practical purpose, impossible. The tool page's own example, 123e4567-e89b-12d3-a456-426614174000, shows the other shape: its 13th character is 1, marking it as version 1, time-based. Learn the two positions and you can classify any UUID you meet in a log file without reaching for a decoder.

Version 4 vs Version 1: Which One to Use

Version 4 is simpler and is the world's default for a reason: 122 of the 128 bits are pure randomness, with 6 bits reserved for the version and variant markers. Fewer moving parts, zero information leakage, and no ordering information of any kind. Use v4 for database keys, API request ids, session tokens, test fixtures, idempotency keys and anything where the identifier should reveal nothing about when or where it was created. Version 1 packs a 60-bit timestamp into the first three groups. The timestamp counts 100-nanosecond intervals since October 15, 1582 — the date of the Gregorian reform, an arbitrary but charming epoch — followed by a 14-bit clock sequence and a 48-bit node identifier. That structure is what makes v1 sortable in creation order, and it is the reason to choose it: on a very large table, time-ordered keys cluster together in a B-tree index instead of scattering randomly, which keeps inserts fast. The same structure is v1's weakness. The timestamp reveals exactly when the id was created, and the node field historically carried the machine's MAC address. This tool sets the multicast bit and uses random node bytes instead, so your hardware address is never exposed — but the creation time is still in there, in plain sight, for anyone who decodes the first twelve hex characters. So the rule is simple: default to v4, and reach for v1 only when creation-order sorting or index clustering is a real, measured need. The tool page also mentions v7, a newer time-ordered version, as an alternative for the same ordering problem; this generator itself offers v1 and v4, and v1 covers the ordering case here.

Where UUIDs Are Used

UUIDs show up anywhere independent systems must agree on identifiers without talking to each other first. Databases are the classic case: in a distributed system, five servers inserting rows at once cannot share an auto-increment counter, so each generates its own UUID primary keys and they never collide. APIs use them as idempotency keys — so retrying a payment cannot charge twice — and as request ids for tracing a call through a dozen microservices, where one identifier follows the request from gateway to database and back. Object storage (S3-style buckets) names uploads with UUIDs to avoid filename clashes when thousands of users upload files with the same name. Session tokens, password-reset links and invitation codes all use UUIDs for the same reason: the value must be unique and unguessable, and nobody wants to run a central counter to hand them out. The unifying theme is decentralised uniqueness: nobody asks permission, nobody checks a registry, and it still works. That property is why UUIDs survived four decades of computing fashion and are now baked into the standard library of nearly every language, from Python's uuid module to Java's UUID.randomUUID(). When you generate a batch here, you are using the same scheme those libraries implement, with the same guarantees.

Common Mistakes

Using v1 where privacy matters. A v1 UUID is a timestamp with a wrapper. Putting one in a public URL, a shared document or an API response tells anyone who decodes it exactly when the record was created. If the creation time is sensitive, use v4. Treating a bare UUID as proof of authorisation. Randomness makes a UUID unguessable, but it carries no expiry, no signature and no revocation. A password-reset link works because the server checks it and expires it, not because the UUID itself is magic; never treat a bare UUID as authorisation on its own. Using a UUID as a password or a secret. For the same reason: a UUID is an identifier, not a credential. It has no hashing, no rotation and no revocation story, and once it leaks it stays valid until something else invalidates it. Generating ids with a weak random source. Math.random() is not a cryptographic generator, and ids built from it are predictable in ways that matter for tokens and reset links. This tool uses the Web Crypto API precisely to avoid that failure. Assuming v4 ids sort. Version 4 UUIDs arrive in random order, so they make poor clustered index keys on huge tables and ugly sort keys in logs. If ordering matters, that is the v1 case, not a reason to sort v4 output and hope. Assuming uniqueness is a substitute for a constraint. UUIDs are practically unique, not provably unique. If your system would catastrophically fail on a duplicate, enforce a uniqueness constraint in the database anyway — the constraint costs nothing and covers the case no probability argument can.

Limits Worth Knowing

UUIDs are the right tool for identity, not for everything. Version 4 UUIDs are not sortable, as above, and they are long for URLs: 36 characters in a path or query string is clunky, which is why URL-shortener-style systems use shorter encodings like Nano ID or base62. Version 1 UUIDs leak information, as above, and even with random node bytes the timestamp remains. A UUID is not a security token by itself, as above. And while collisions are cosmically unlikely, they are not impossible: the tool page puts it memorably — you could generate a billion UUIDs per second for 85 years and still have only a fifty-fifty chance of a single collision. For every real-world application, they behave as unique, and that is the correct way to think about it: unique in practice, not unique by proof. Used with those limits in mind, the generator does its job cleanly. It produces standards-compliant v1 and v4 identifiers, in batches of up to 100, with copy controls that fit straight into code, and it does it without your identifiers ever leaving your device. That combination — a real standard, a secure random source, and no server in the loop — is everything a UUID generator needs to do. The companion guides for the same developer workflow are our Base64 guide, for the other encoding developers reach for daily, our JSON formatting guide, for the data those identifiers usually travel with, and our regex testing guide, for validating the patterns that check identifiers before they ever reach a database.

Frequently Asked Questions

More guides from ToolNest