About UUID v1 (Time-based)
UUID v1 Generator produces time-based identifiers, where the leading part of the value is derived from a timestamp counted in hundred-nanosecond intervals since October 1582 — the epoch chosen because it predates the Gregorian calendar reform. Because the time component dominantly determines the ordering, identifiers created close together sort close together as strings, which is often exactly what you want for database keys and log records.
The timestamp and the remaining fields are arranged so that the whole value sorts in creation order. That property is the practical reason to choose version 1 over the fully random version 4: appending a roughly increasing key to an index is much cheaper than scattering insertions across it, and the identifier still fits in the standard sixteen-byte form.
One implementation detail is worth being explicit about. The trailing field of a classic version 1 identifier is a hardware node address, in practice the network interface MAC address, which embeds a permanent device identifier in every value. This generator does not read your hardware address; it fills that field with fresh random bytes and uses a random value for the clock sequence as well. The identifiers are therefore time-ordered but do not leak the machine they came from, and they should not be treated as a strictly conformant replacement where an audit trail expects a real hardware node identifier.
How to use UUID v1 (Time-based)
- 1 Set how many identifiers to generate, up to a hundred.
- 2 Copy the list, which comes back one identifier per line.
- 3 Treat the order as indicative of creation time rather than as a guaranteed strict sequence.
Frequently asked questions
Does it read my network card address?
No. The node field is filled with random bytes instead, which keeps a permanent hardware identifier out of values that are likely to be logged or published. The trade-off is that these are not strictly conformant version 1 identifiers in the sense an audit process might expect.
Are they guaranteed to be unique?
Practical uniqueness comes from the combination of a high-resolution timestamp and the random trailing field, together with the random clock sequence. Generating many in the same millisecond is not a problem, but the ordering within that millisecond is not guaranteed to be strictly increasing.
Are version 1 identifiers a privacy risk?
They are in the classic form, because the node field embeds a hardware address that persists across sessions and can be correlated. This generator avoids that specific leak by randomising the field; if the identifier will be shown publicly, that difference is worth knowing about.
Should I use version 1 or version 4 identifiers?
Choose version 1 when the storage layer benefits from roughly sequential keys and the ordering is genuinely useful. Choose version 4 when the value will be exposed and you want it to carry no timestamp at all, since a time-based identifier reveals when the record was created.
Free, online, and private
Free to use
UUID v1 (Time-based) is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How UUID v1 (Time-based) behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Version nibble | always 1 — the character is written literally into the template string |
| Batch output | 1 – 100 per run, default 5, clamped with Math.min(100, Math.max(1, …)) |
| Node field | six bytes from crypto.getRandomValues — the machine MAC address is never read |
| Variant bits | the first byte of the fourth group is 0x80 | a random value below 0x40, the RFC 4122 10xx form |
| Clock sequence | the remaining bits come from Math.random(), not from a stored counter, so they are redrawn per call |
| Epoch constant | 0x01b21dd213814000, the 1582-to-1970 offset in 100-nanosecond units |
Compiled from the implementation of this tool and checked against it by itoolnet.
What UUID v1 (Time-based) does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- The timestamp cannot advance. The current seconds are added to the 1582 offset while both are ordinary doubles, and at roughly 1.2 × 10^17 a double can only step by 16, so the sum is identical one, two and five seconds later; only the millisecond remainder moves the digits.
- The value overflows the field it is written into: the extra ×10000 scaling makes the time component 18 hex digits where the 64-bit v1 layout expects 16, and the template keeps only slices 0-7, 8-11 and 13-15, discarding the character at index 12 and the final two.
- Nothing can be supplied from outside. Both the instant and the node are read inside the function on every call, so a value produced here cannot be reproduced, cannot be tied back to the machine that made it, and cannot be generated deterministically for a test.
Tested and documented by itoolnet, the team that builds and maintains this site.