UUID Generator Version 1 (V1)

UUID v1 · Gregorian time-based Generated in your browser. Nothing is sent to any server.

Shortcuts: C copy · R new uuid · G generate bulk

Timestamp
Node ID
Clock sequence
Format
Style
Separator

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

PartValueBitsWhat it holds
time_low8fdbd73532Lowest bits of the timestamp
time_midc61716Middle bits of the timestamp
time_hi + version11f116Version 1, then the top 12 timestamp bits (1f1)
variant + clock sequence8b2116Variant bits 10, then a 14-bit clock sequence (2849)
nodef3a752e6b43848Node 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:

  1. Third group: it starts with 1. This is the version digit, the 15th character of the string (11f1).
  2. Fourth group: it starts with 8, 9, a, or b. 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.

#FieldBitsExampleWhat it holds
1time_low328fdbd735Lowest part of the timestamp
2time_mid16c617Middle part of the timestamp
3version41Always 0001 for v1
4time_hi121f1Highest part of the timestamp
5variant210Marks the RFC 9562 layout
6clock_seq140b21Clock sequence (2849)
7node48f3a752e6b438Node 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:

  1. 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.
  2. 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.
  3. 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:50ee1e5d00-c617-11f1-8b21-f3a752e6b438
08:36:5011e1a300-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.

VersionUUID
v18fdbd735-c617-11f1-8b21-f3a752e6b438
v61f1c6178-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

FieldWhat an observer can learn
TimestampThe exact creation time, down to 100 ns, in UTC
NodeThe machine itself, if it holds a real MAC address
Clock sequenceWhich 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

  1. Use a random node. Tools like PostgreSQL’s uuid_generate_v1mc() or a custom node in a generator do this.
  2. Keep v1 values inside your system, not in public URLs or API responses.
  3. Treat the timestamp as public information whenever a v1 leaves your servers.
  4. 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.

AdvantagesLimitations
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 v1UUID v4UUID v6UUID v7
Built fromTimestamp, clock sequence, nodeRandom bitsSame fields as v1, reorderedUnix timestamp plus random bits
Timestamp100 ns ticks since 1582None100 ns ticks since 1582Milliseconds since 1970
Sorts as plain textNoNoYesYes
Machine dataPossible (real MAC)NonePossible (real MAC)None
PredictableYesNo, with a secure random sourceYesPartly: time is visible
RFC 9562 section5.15.45.65.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.

FieldBitsValue
random_a48Random
ver40100
random_b12Random
var210
random_c62Random

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.1What RFC 9562 does about it
MAC address privacy and security risksAdds guidance on hiding the host (Section 6.10)
The 1582 epoch is hard to represent in common number formatsDefines v7 on the Unix epoch
Time order needs parsing, not a byte-by-byte comparisonAdds v6 (reordered) and v7 (time-ordered)
Layout ambiguity reported in RFC 4122 errataPublishes 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.

  1. Create a UUID. Click New UUID in the generator to create a version 1 value.
  2. Set the time. Under Timestamp, keep Current time, or switch to Custom time to encode a date of your choice.
  3. 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.
  4. Choose the output. Pick a Format, Style, Quotes and Byte order option. Standard format with hyphens is the usual choice.
  5. Make many at once. Select a quantity from 1 to 1,000 and a Separator, then click Generate UUIDs.
  6. Copy the result. Click Copy, or press C. Press R for a new UUID and G for bulk generation.

Frequently Asked Questions (FAQ’s)

Only when the node field holds a real MAC address, which some libraries and database functions use by default. The generator’s Random node option avoids that link. The creation time stays visible either way.

Join the three time fields into one 60-bit number, treat it as 100 ns ticks since 15 October 1582, and convert it to a date. In Python, the .time attribute of a UUID object gives that number directly. The full decode is shown above.

Not as plain text, because the low part of the timestamp comes first in the string. Convert the value to v6, or use v7, when you need time order.

Only the first group changes quickly. The next group moves about every seven minutes, and the node and clock sequence stay fixed for one source.

Yes. MySQL’s UUID() returns a version 1 value, and on Linux, Windows and FreeBSD it uses the server’s real MAC address. UUID_TO_BIN(value, 1) can reorder the time parts for storage.

Yes. UUID v6 keeps every v1 field and only reorders the time bytes, so the same time, clock sequence and node carry over. A worked example is shown above.

Yes. RFC 9562 still defines it in Section 5.1, although the standard recommends v7 for new systems.

No. Values from one source are predictable, so use v1 to name records and a secure random token for anything that grants access.

Yes. Choose Current time or Custom time, a random or custom MAC node, and a random or custom clock sequence. Then generate up to 1,000 UUIDs at once.

It swaps the byte order of the first three fields to match how Microsoft GUID structures store them, so the hex text differs from the standard RFC 9562 form. Keep Standard unless a Windows or .NET system needs the other layout.

Related UUID Tools