About UUID Generator
UUID Generator produces version 1, version 4, or version 7 identifiers, up to a thousand at a time, one per line. The version selector is the entire decision: it determines what the identifier encodes, how it sorts, and what it discloses.
All three are 128-bit values printed as 36 characters in the same 8-4-4-4-12 layout, differing only in how the bits are filled. Version 4 is 122 random bits. Version 1 packs a 60-bit timestamp in 100-nanosecond ticks, a clock sequence, and a node identifier. Version 7, standardized in RFC 9562 in 2024, leads with a 48-bit Unix millisecond timestamp, so lexical order matches creation order.
How to use this developer tool
- Pick the version: 7 for a database key, 4 when the identifier must reveal nothing, 1 only when a system you do not control requires it.
- Set the quantity, from 1 to 1000.
- Generate. Values arrive one per line, ready for a fixture file, a seed script, or a spreadsheet column.
- Spot-check the 13th hex digit of one value to confirm you generated the version you meant to.
- Record the choice next to the column definition. A consumer assuming version 7 ordering fails silently the day someone inserts a version 4.
Worked example: three version 7 values from the same millisecond
A batch of three from one click, all produced inside the same millisecond, so they share their leading timestamp bits and still sort in generation order as plain strings.
Version v7
Quantity 301a0c2c8-1e60-72be-b631-62ee8a95c283
01a0c2c8-1e60-72be-b631-677245e7e821
01a0c2c8-1e60-72be-b631-6b4e18f0a5f8The leading 12 hex digits are the timestamp: 0x01a0c2c81e60 is 1789974290016, or 2026-09-21T07:04:50.016Z. The 13th digit is 7 and the 17th is b. Compare a version 4 from the same session, d5bd8caa-62c8-4afd-a4da-ebef1311b3bd, where nothing is ordered or decodable.
UUID versions: what each encodes and how it sorts
This tool generates versions 1, 4, and 7. The others are listed because they come up whenever the choice is made seriously.
| Version | What the bits carry | Time-ordered | What it discloses |
|---|---|---|---|
| v1 | 60-bit timestamp, 14-bit clock sequence, 48-bit node | No — low timestamp bits print first | Creation time; the MAC address where one can be read |
| v4 | 122 random bits | No | Nothing |
| v7 | 48-bit Unix millisecond timestamp, then randomness | Yes, as string and as bytes | Creation time, to the millisecond |
| v3 / v5 | MD5 / SHA-1 of a namespace plus a name | No | The name, to anyone who can guess and recompute it |
| v6 | v1 with the timestamp most-significant first | Yes | Same as v1 — not offered here |
| v8 | Implementation-defined | Depends | Whatever the implementation put in it |
Troubleshooting
Inserts slow down and the primary-key index grows faster than expected under v4 keys.
Why it happens A random key writes to a random B-tree page, so every insert touches a different leaf. The hot working set becomes the whole index instead of its tail, and page splits leave pages partly empty.
Fix Generate new rows with v7, whose values increase monotonically so inserts land on the rightmost leaf. This index locality is the main practical reason v7 exists.
A public API is leaking record creation times through its identifiers.
Why it happens That is v7 working as designed: the first 12 hex digits are milliseconds since the Unix epoch, and adjacent identifiers reveal roughly how many records you create per second.
Fix Keep v7 as the internal key and expose a separate opaque public identifier whenever creation time or record volume is sensitive.
A security review flags v1 identifiers as exposing a MAC address.
Why it happens Classic v1 implementations read the network interface and embed it, making every identifier traceable to a machine. It is a real finding against server-side generators.
Fix Values generated here need no fix, since the node field is random with the multicast bit set. Audit server-side v1 generators and move anything user-facing to v7 or v4.
A bulk import produced duplicate key errors.
Why it happens Almost certainly not a v4 collision: with 122 random bits you need on the order of 10^18 identifiers before there is a coin-flip chance of any collision.
Fix Look for the import running twice, an upsert missing its conflict clause, or a fixture loaded again. Braced or uppercase GUIDs also do not compare equal to lowercase unbraced ones.
When this tool is the right choice
- Creating primary keys the client can generate before any round-trip to the database.
- Filling a fixture or seed file with a batch of realistic, distinct identifiers.
- Producing correlation or trace identifiers unique across services without coordination.
- Choosing between ordered and opaque identifiers by generating both and comparing them.
When to use something else
- Short public identifiers. Thirty-six characters is a lot of URL; re-encode the same bits in a denser alphabet with the Number Base & Radix Converter.
- Secrets and capability tokens. A v4 carries 122 random bits, but v1 and v7 are partly predictable, and UUIDs are routinely logged and printed in URLs. Use the Secure Password Generator instead.
- Identifiers a human reads out or types. Nobody transcribes a UUID correctly; use a short code with a check character.
Privacy and data handling
Every value is generated in this tab and nothing is transmitted or stored; randomness for versions 4 and 7 comes from the browser's cryptographically secure source. One point deserves a clear answer: a browser cannot read network hardware addresses, so version 1 here fills the node field with a random 48-bit value carrying the multicast bit, the fallback RFC 9562 prescribes. Its timestamp is real, so the value discloses when it was made, but not where.
Related developer tools
Frequently asked questions
Which version should I default to?
Version 7 for stored records, because the index locality is free and the ordering is often useful. Version 4 when the identifier is exposed and must reveal nothing about timing or volume.
Is version 7 actually standard?
Yes. RFC 9562, published in May 2024, obsoleted RFC 4122 and formally defines versions 6, 7, and 8. Major databases and client libraries have been adding native version 7 generators since.
Does a UUID guarantee uniqueness?
No. It makes a collision improbable enough to plan around, but that is a probability argument. Keep the unique constraint: it catches the real causes of duplicates, which are replayed imports and copied fixtures.
Should I store a UUID as text or as bytes?
As a native uuid type where the database has one, otherwise as 16 binary bytes. The text form takes twice the space, and its dashes and letter case cause recurring comparison bugs.
Does version 7 sorting hold across multiple machines?
Only as well as their clocks agree. Within one generator values are monotonic; across servers with a few milliseconds of skew the global order is approximate — fine for index locality, but not a replacement for a sequence.
Why do my version 7 values look almost identical?
Values created in the same millisecond share their first 12 hex digits by design, because those digits are the timestamp. That shared prefix is exactly what keeps them cheap to index.