UUID Generator Version 1 (V1)
Shortcuts: C copy · R new uuid · G generate bulk
Generate UUID v1 values from the current time or a custom timestamp. A UUID v1 is a 128-bit, time-based identifier built from a timestamp, a clock sequence, and a node. Create up to 1,000 at once, free, with no sign-up and nothing sent to a server.
What Is UUID v1?
A UUID v1 is a 128-bit identifier built from the time it was created, a clock sequence, and a node ID. The timestamp counts 100-nanosecond steps from 15 October 1582, which is why v1 is called a Gregorian time-based UUID.
Because the time is part of the ID, you can read the creation moment back from any v1 value. The clock sequence and node keep two IDs apart when they are made at the same instant.
Example UUID v1
Here is one UUID v1, split into its parts:8fdbd735-c617-11f1-8b21-f3a752e6b438
| Part | Value | Bits | What it holds |
|---|---|---|---|
| time_low | 8fdbd735 | 32 | Lowest bits of the timestamp |
| time_mid | c617 | 16 | Middle bits of the timestamp |
| time_hi + version | 11f1 | 16 | Version 1, then the top 12 timestamp bits (1f1) |
| variant + clock sequence | 8b21 | 16 | Variant bits 10, then a 14-bit clock sequence (2849) |
| node | f3a752e6b438 | 48 | Node ID |
Put the timestamp parts back together and this UUID decodes to 12 October 2026, 08:33:12.529 UTC. The node starts with f3, whose lowest bit is 1. RFC 9562 uses that bit to mark a random node instead of a real MAC address.
How to Spot a UUID v1
Two characters tell you most of what you need:
- Third group: it starts with
1. This is the version digit, the 15th character of the string (11f1). - Fourth group: it starts with
8,9,a, orb. This is the variant digit used by RFC 9562 (8b21).
If both checks pass, you are looking at a UUID v1. You can also paste any UUID into the generator’s UUID Version Checker to confirm it.
How the 128 Bits Are Laid Out
A UUID v1 splits its 128 bits into seven fields. The generator above colour-codes these same fields live, so you can match each part to the value it produced.
Field Table
The example below uses 8fdbd735-c617-11f1-8b21-f3a752e6b438.
| # | Field | Bits | Example | What it holds |
|---|---|---|---|---|
| 1 | time_low | 32 | 8fdbd735 | Lowest part of the timestamp |
| 2 | time_mid | 16 | c617 | Middle part of the timestamp |
| 3 | version | 4 | 1 | Always 0001 for v1 |
| 4 | time_hi | 12 | 1f1 | Highest part of the timestamp |
| 5 | variant | 2 | 10 | Marks the RFC 9562 layout |
| 6 | clock_seq | 14 | 0b21 | Clock sequence (2849) |
| 7 | node | 48 | f3a752e6b438 | Node ID |
The timestamp is not stored in one piece. Its 60 bits are joined in the order time_hi, time_mid, time_low.
Version and Variant Bits
The 4 version bits are always 0001, and the 2 variant bits are always 10. That is why the fourth group starts with 8, 9, a, or b.
Reading the Timestamp
The 60-bit timestamp is the only part of a UUID v1 that tells you when it was made. Reading it takes three small steps.
Cryptographically Secure Randomness
A cryptographically secure random number generator (CSPRNG) is built so that its output cannot be predicted, even by someone who has seen earlier values. Operating systems seed it from unpredictable system entropy.
This generator uses crypto.getRandomValues(), the Web Crypto API built into your browser. That is a CSPRNG, so each UUID v4 here comes from a cryptographically secure source, not from Math.random().
The 1582 Start Date and 100 ns Ticks
The count starts at 00:00 UTC on 15 October 1582, the day the Gregorian calendar took effect in the first countries that adopted it. Each tick is 100 nanoseconds, so one second holds 10 million ticks.
Decode It Step by Step
Using 8fdbd735-c617-11f1-8b21-f3a752e6b438:
- Reassemble. Join time_hi, time_mid, and time_low in that order:
1f1+c617+8fdbd735=0x1f1c6178fdbd735, which is 140,110,867,925,292,853 ticks. - Move to the Unix epoch. Subtract 141,427 days, the gap between 15 October 1582 and 1 January 1970. That is 122,192,928,000,000,000 ticks, leaving 17,917,939,925,292,853.
- Convert. Divide by 10,000 (ticks per millisecond) to get Unix time in milliseconds: 1,791,793,992,529. That is 12 October 2026, 08:33:12.529 UTC.
Why v1 Looks Out of Order
The lowest timestamp bits come first in the string, and time_low is only 32 bits. At 100 ns per tick, it wraps around every 7.16 minutes (2³² × 100 ns ≈ 429.5 seconds).
When it wraps, a later UUID can start with a smaller value. These two were made 60 seconds apart:
| Created (UTC) | UUID v1 |
|---|---|
| 08:35:50 | ee1e5d00-c617-11f1-8b21-f3a752e6b438 |
| 08:36:50 | 11e1a300-c618-11f1-8b21-f3a752e6b438 |
Sort them as text and the later one comes first. To order v1 values by time, decode the timestamp first, or use a version that stores the time bits in sortable order, such as UUID v7.
The Node Field and MAC Address
The node is the last 48 bits of a UUID v1. It tells two machines apart, so they can create IDs at the same moment without clashing.
What the Node Holds
The original design put the machine’s MAC address here, the 6-byte hardware address of its network card. In the example, the last group f3a752e6b438 is the node. The generator shows it in MAC style as F3:A7:52:E6:B4:38.
Random Node and the Multicast Bit
RFC 9562 (section 6.10) allows a random node for systems that should not expose a hardware address. The generator must set the multicast bit to 1. That is the lowest bit of the first byte, so the second hex digit of the node is odd (1, 3, 5, 7, 9, b, d, or f).
Real network cards always send with this bit at 0. A random node can therefore never match a real MAC address.
Why Web Tools Use a Random Node
A web page cannot read your computer’s MAC address, so a browser-based generator has nothing real to put in the node field. This tool fills it with a random value by default, and the Node ID option lets you enter your own.
Clock Sequence and Uniqueness
A UUID v1 stays distinct by combining three things: the time, the node, and the clock sequence. This section covers the third one and how it guards against duplicates.
What the Clock Sequence Does
The clock sequence is a 14-bit number, so it runs from 0 to 16,383. RFC 9562 names two cases it protects against: the system clock being set backwards, or the node ID changing. In both, the same timestamp and node could appear twice, and a different clock sequence keeps the two UUIDs apart.
A generator starts it at a random value and adds 1 each time the clock moves backwards. In this tool, you can enter the value yourself or leave it random.
How Duplicates Are Prevented
Two UUID v1 values can only match if they share the same host, the same timestamp tick, and the same clock sequence. One host can ask for several IDs inside a single tick, so a careful generator either waits for the next tick or returns an error, as RFC 9562 advises.
For a hard guarantee, add a unique constraint on the UUID column. The database then rejects any duplicate that slips through. If you do not need time inside the ID, how UUID v4 uniqueness works shows a random-based alternative.
Sorting and Databases
UUID v1 was not designed for sorted storage, and databases show it quickly. This section covers the problem, the built-in fixes, and better options.
Why Plain Sorting Fails
The 7.16-minute wrap shown in Why v1 Looks Out of Order also affects indexes. An index orders values by their bytes, and time_low comes first, so new v1 rows land at scattered positions instead of at the end.
MySQL and PostgreSQL
MySQL’s UUID() returns a UUID v1. Store it as BINARY(16) with the swap flag, which moves the fast-changing time_low part to the right:
INSERT INTO orders (id) VALUES (UUID_TO_BIN(UUID(), 1));
SELECT BIN_TO_UUID(id, 1) FROM orders;
PostgreSQL generates v1 through the uuid-ossp extension. The v1mc variant uses a random multicast node instead of the host’s real MAC address:
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
SELECT uuid_generate_v1();
SELECT uuid_generate_v1mc();
Better Choices: v6 and v7
Two newer versions keep the time idea but store it in sortable order.
Convert v1 to v6
UUID v6 holds the same timestamp, clock sequence, and node as v1. Only the timestamp bits are reordered, highest first, so the values sort by time.
| Version | UUID |
|---|---|
| v1 | 8fdbd735-c617-11f1-8b21-f3a752e6b438 |
| v6 | 1f1c6178-fdbd-6735-8b21-f3a752e6b438 |
The last two groups are unchanged, and the version digit changes from 1 to 6.
Move to v7 for New Systems
For new projects, UUID v7 is the usual choice. It stores a Unix millisecond timestamp followed by random bits, and PostgreSQL 18 includes a built-in uuidv7() function. You can try it in the UUID v7 Generator.
Privacy and Security
A UUID v1 carries more than an identifier. Anyone who holds one can read when it was created and, depending on the node, link it to the machine that made it.
What a v1 Exposes
| Field | What an observer can learn |
|---|---|
| Timestamp | The exact creation time, down to 100 ns, in UTC |
| Node | The machine itself, if it holds a real MAC address |
| Clock sequence | Which IDs likely came from one source, since it rarely changes on a host |
A fixed node and clock sequence let anyone group IDs from the same source. A random node removes the hardware link, but the timestamp always stays visible.
Predictable, Not Secret
Two v1 UUIDs from the same source differ only in a small timestamp step. Once someone sees one, the next values are easy to estimate.
That makes v1 a poor choice for password-reset links, session IDs or invite codes. Use it to name records, not to protect them.
Reducing Exposure
- Use a random node. Tools like PostgreSQL’s
uuid_generate_v1mc()or a custom node in a generator do this. - Keep v1 values inside your system, not in public URLs or API responses.
- Treat the timestamp as public information whenever a v1 leaves your servers.
- For public identifiers, choose v4 or v7. v7 shows creation time but no machine data.
Python’s documentation warns that uuid1() can compromise privacy because it embeds the computer’s network address. MySQL’s UUID() also uses the real MAC address on Linux, Windows and FreeBSD.
Advantages and Limitations
UUID v1 is a good fit for some jobs and a poor one for others. This table sums up what the sections above already cover.
| Advantages | Limitations |
|---|---|
| Needs no central server or coordination. Any machine can generate one offline. | Creation time is visible to anyone who holds the UUID. |
| Time, node and clock sequence together keep IDs unique across hosts. | A real MAC address in the node field can point to the machine. |
| The creation time can be decoded later, with 100 ns precision. | The string does not sort by time as plain text. |
| Built into MySQL, PostgreSQL, Python and Go. | Values from one source are predictable, so it is unsafe as a token. |
| Fields can be reordered into v6 with the same data. | A clock that moves backward needs correct clock sequence handling. |
| Works for naming records inside a closed system. | v6 and v7 suit new, index-heavy projects better. |
UUID v1 vs Other Versions
Each version builds its 128 bits from a different source. The table shows the differences at a glance, and the sections below explain the pairs that matter most.
| UUID v1 | UUID v4 | UUID v6 | UUID v7 | |
|---|---|---|---|---|
| Built from | Timestamp, clock sequence, node | Random bits | Same fields as v1, reordered | Unix timestamp plus random bits |
| Timestamp | 100 ns ticks since 1582 | None | 100 ns ticks since 1582 | Milliseconds since 1970 |
| Sorts as plain text | No | No | Yes | Yes |
| Machine data | Possible (real MAC) | None | Possible (real MAC) | None |
| Predictable | Yes | No, with a secure random source | Yes | Partly: time is visible |
| RFC 9562 section | 5.1 | 5.4 | 5.6 | 5.7 |
v1 vs v4
A v4 UUID is almost entirely random, so it carries no time and no machine data. A v1 UUID carries both, which makes it decodable but also traceable.
Choose v4 when the ID should reveal nothing. Choose v1 when the creation time matters to you.
v1 vs v6
v6 holds the same fields as v1, with the timestamp bytes placed in the order that sorts correctly. Nothing else about the data changes.
That makes v6 a drop-in upgrade for systems that already depend on v1-style values and now need sorted keys.
v1 vs v7
v7 drops the node and clock sequence and uses a Unix millisecond timestamp plus random bits instead. It carries no machine data, and it sorts naturally.
The trade-off is precision: v1 counts in 100 ns steps, while v7 counts in milliseconds. For most applications, that gap does not matter.
Which One to Choose
- Keep v1 if existing data or a legacy system already uses it.
- Use v4 when you need an identifier that reveals nothing.
- Use v6 if you need sorted keys but must stay compatible with v1-style fields.
- Use v7 for new projects, especially database primary keys.
RFC 9562 still defines v1, so it is not obsolete. It is simply no longer the first choice for new systems.
RFC 9562 and RFC 4122
RFC 9562 is the current UUID standard. It replaced RFC 4122 and keeps UUID v1 as one of its defined versions.
Where v1 Is Defined
The RFC also recommends a cryptographically secure source for the random bits. This is the same layout explained step by step in the “How Does UUID v4 Work?” section above.
| Field | Bits | Value |
|---|---|---|
| random_a | 48 | Random |
| ver | 4 | 0100 |
| random_b | 12 | Random |
| var | 2 | 10 |
| random_c | 62 | Random |
RFC 9562 obsoletes RFC 4122. The v1 layout and the 60-bit timestamp stay the same, so existing v1 values remain valid.
Why It Was Revisited
Section 2.1 of RFC 9562 explains why the standard needed an update. Four of its reasons concern v1 directly.
| Issue named in Section 2.1 | What RFC 9562 does about it |
|---|---|
| MAC address privacy and security risks | Adds guidance on hiding the host (Section 6.10) |
| The 1582 epoch is hard to represent in common number formats | Defines v7 on the Unix epoch |
| Time order needs parsing, not a byte-by-byte comparison | Adds v6 (reordered) and v7 (time-ordered) |
| Layout ambiguity reported in RFC 4122 errata | Publishes a clearer layout and more test vectors |
The standard also states a preference: “Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible.” This is guidance for new systems, not a withdrawal of v1.
Programming Examples
Each snippet below creates a version 1 UUID. Where the library allows it, you can also set the node and clock sequence yourself.
JavaScript
Install the package with npm install uuid. From version 12 on it is ES module only, so use import. By default it picks a random node, not your MAC address.
import { v1 as uuidv1 } from 'uuid';
console.log(uuidv1());
// Fixed node and clock sequence
console.log(
uuidv1({
node: Uint8Array.of(0x01, 0x23, 0x45, 0x67, 0x89, 0xab),
clockseq: 0x1234,
})
);
Python
The uuid module is builtZ in. Without arguments, uuid1() uses the machine’s hardware address when it can find one.
import uuid
from datetime import datetime, timedelta, timezone
u = uuid.uuid1()
# Read the creation time (100 ns ticks since 1582-10-15)
start = datetime(1582, 10, 15, tzinfo=timezone.utc)
created = start + timedelta(microseconds=u.time // 10)
print(u)
print(created.isoformat())
# Fixed node and clock sequence
print(uuid.uuid1(node=0x0123456789AB, clock_seq=1234))
Go
Add the package with go get github.com/google/uuid. NewUUID() returns a version 1 UUID, and SetNodeID() lets you fix the node.
package main
import (
"fmt"
"github.com/google/uuid"
)
func main() {
id, err := uuid.NewUUID() // version 1
if err != nil {
panic(err)
}
fmt.Println(id)
// Fixed node (first 6 bytes are used)
uuid.SetNodeID([]byte{0x01, 0x23, 0x45, 0x67, 0x89, 0xab})
id2, _ := uuid.NewUUID()
fmt.Println(id2)
}
Rust
In Cargo.toml, enable the v1, std and rng features: uuid = { version = "1", features = ["v1", "std", "rng"] }. Rust does not pick a node for you, so you pass a 6-byte one.
use uuid::Uuid;
fn main() {
// You supply the 6-byte node yourself
let node_id = [0x01, 0x23, 0x45, 0x67, 0x89, 0xab];
let id = Uuid::now_v1(&node_id);
println!("{}", id);
}
PHP
Install the library with composer require ramsey/uuid (PHP 8.0 or newer).
<?php
require 'vendor/autoload.php';
use Ramsey\Uuid\Uuid;
$uuid = Uuid::uuid1();
echo $uuid->toString() . PHP_EOL;
echo $uuid->getFields()->getVersion() . PHP_EOL;
MySQL
UUID() returns a version 1 value. The commands below are for quick copy and paste, since the reason for the swap flag is explained under Sorting and Databases.
SELECT UUID();
-- Swap the time parts for better index order
SELECT UUID_TO_BIN(UUID(), 1);
-- Convert it back to text
SELECT BIN_TO_UUID(UUID_TO_BIN(UUID(), 1), 1);
PostgreSQL
The uuid-ossp extension provides both functions. The v1mc version replaces the real MAC address with a random multicast node.
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
SELECT uuid_generate_v1();
-- Random multicast node instead of the real MAC
SELECT uuid_generate_v1mc();
How to Generate UUID v1 Online
The generator above creates a version 1 UUID in a few clicks. Every setting except the quantity is optional.
- Create a UUID. Click New UUID in the generator to create a version 1 value.
- Set the time. Under Timestamp, keep Current time, or switch to Custom time to encode a date of your choice.
- Set the node and clock sequence. Under Node ID, choose Random, New random for every UUID, or a Custom MAC address. The clock sequence can stay Random or be set by hand.
- Choose the output. Pick a Format, Style, Quotes and Byte order option. Standard format with hyphens is the usual choice.
- Make many at once. Select a quantity from 1 to 1,000 and a Separator, then click Generate UUIDs.
- Copy the result. Click Copy, or press C. Press R for a new UUID and G for bulk generation.
