UUID v1 Generator

UUID v1 is the timestamp-based variant from RFC 4122. Useful for legacy interop; for new code you almost certainly want v7 instead.

Anatomy of a v1 UUID

A UUID v1 looks like e0c2c0d4-23a9-11ee-be56-0242ac120002. The first three groups are derived from the timestamp (with the bytes reordered, which is why v1 doesn't sort chronologically). The fourth group is the clock sequence, and the last group is the node ID.

v1 vs v4

v1 embeds time and identity; v4 is purely random. v1 was meant to guarantee uniqueness across machines using the MAC address, but that guarantee evaporated once libraries (rightly) started randomizing the node ID.

v1 vs v7

Both encode time. v7 puts the timestamp at the start in a way that makes lexicographic sort match time order — which is hugely useful for database indexes. If you're choosing today, choose v7.

How this generator works

We use the uuid npm package's v1(), which seeds a random 48-bit node ID per page load. Generation runs entirely in your browser; no UUID ever touches our server.

v1 in code

// JavaScript / TypeScript
import { v1 } from "uuid";
v1(); // "ae67e620-40e1-11f1-9145-c3cf0cb6034e"

// Python
import uuid
uuid.uuid1()

// PostgreSQL (with uuid-ossp extension)
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
SELECT uuid_generate_v1();    -- with MAC address
SELECT uuid_generate_v1mc();  -- with random node ID (recommended)

Decoding a v1 timestamp

Given a v1 UUID, you can recover the time it was generated. The first three groups encode 100-nanosecond intervals since the Gregorian-calendar epoch (1582-10-15 UTC), with the bytes reordered for legacy reasons.

function decodeV1Time(uuid) {
  const [low, mid, hi] = uuid.split("-");
  // strip version nibble, reassemble in chronological byte order
  const hex = hi.slice(1) + mid + low;
  const ticks100ns = BigInt("0x" + hex);
  const UUID_EPOCH_MS_BEFORE_UNIX = 12219292800000n;
  const ms = ticks100ns / 10000n - UUID_EPOCH_MS_BEFORE_UNIX;
  return new Date(Number(ms));
}

Or just paste the UUID into the validator — it decodes the timestamp automatically.

Real-world use cases

• Legacy interop. If you're integrating with a system from the early 2000s — older Windows COM components, some Java EE applications, classic Oracle databases — v1 may be the format you're handed.
• Forensic timestamping. When you receive a v1 UUID from a third party, you can recover its generation time even years after the fact.
• Migrating off v1. Many older codebases used v1 as a primary key and now want time-ordered keys with better properties — v1 → v7 migration is a common path.

Common pitfalls

• Lexicographic sort doesn't match chronological. v1's timestamp bytes are reordered by spec. Sorting v1 UUIDs as strings does not sort them by time. Use v7 if you need that.
• MAC-address leaks from old systems. If a third party's v1 UUIDs were generated on a server that didn't randomize the node ID, the last group may contain that machine's actual MAC. Treat third-party v1 UUIDs as potentially identifying.
• Clock rewinds break monotonicity. If the system clock goes backwards (NTP correction, VM resume), v1 generators bump the clock-sequence to keep uniqueness, but the UUIDs from before and after the rewind are no longer in chronological order.