ModernUUID Icon ModernUUID
โœจ OFFICIAL RFC 9562 SPECIFICATION (2024)

UUID v7 Generator (Chronological & Time-Ordered)

Version 7 replaces legacy random UUIDs in modern database architectures by encoding an unsigned big-endian Unix millisecond timestamp in the highest 48 bits, delivering sequential B-tree database index inserts and natural time-sorting.

Select Identifier Architecture
RFC 9562 NEW STANDARD

Online UUID Version 7 Generator Tool

Time-ordered Unix millisecond timestamp combined with random sequence bytes. Optimal for database B-tree indexing and chronological indexing.

Generated Output:
Generatingโ€ฆ
Formatting & Manipulation Options

The Engineering Revolution of UUID Version 7 (RFC 9562)

Standard Reference: IETF RFC 9562 ยง5.7 (Published May 2024, superseding RFC 4122)

RFC 9562 Structural Bit Layout

Unlike Version 4 (pure randomness) or Version 1 (Gregorian timestamp + hardware MAC), Version 7 establishes an elegant hybrid format engineered for modern database and microservice performance:

unix_ts_ms (48 Bits) 12 Hex Characters

Unsigned 48-bit integer representing milliseconds elapsed since Unix epoch (Jan 1, 1970 UTC). Valid until the year 10889 AD.

ver + rand_a (16 Bits) 4 Hex Characters (0x7...)

4 bits set to 0111 (Version 7) + 12 bits of secure pseudorandom entropy or sub-millisecond sequence counter.

var + rand_b (64 Bits) 16 Hex Characters (0x8..B...)

2 bits set to 10xx (RFC 4122/9562 variant) + 62 bits of cryptographically unguessable hardware randomness.

Total Entropy 74 Bits of Randomness

Provides up to 2โทโด unique combinations within the exact same millisecond per generating node, eliminating collision risk.

Why UUID v7 Fixes Database Index Fragmentation

In relational database management systems (such as PostgreSQL, MySQL InnoDB, SQLite, and Microsoft SQL Server), primary keys are stored in B-Tree (B+ Tree) indexes.

โŒ The UUID v4 Bottleneck

Because UUID v4 keys are completely random, every new database insert lands at an arbitrary location across the index leaf pages. Once a table grows beyond cache memory (RAM), inserting new records forces the storage engine to read random index pages from disk, split full pages in half, and rebalance the tree. This causes severe disk I/O thrashing and write amplification at scale.

โœ… The UUID v7 Solution

Because UUID v7 keys start with a 48-bit millisecond timestamp, newly created keys are naturally sequentially higher than previously created keys. New database inserts append cleanly to the right-most edge of the B-Tree index, maximizing buffer pool cache hit rates, preventing index fragmentation, and matching the write performance of auto-incrementing integers!

Database Schema Examples

// PostgreSQL 17+ / Prisma Schema
-- PostgreSQL 17 native support:
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT uuid_generate_v7(),
    customer_id UUID NOT NULL,
    total_amount NUMERIC(10, 2) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Querying by time range directly from UUID:
SELECT * FROM orders 
WHERE id >= '018e4700-0000-7000-8000-000000000000';
// TypeScript / Node.js Generation
import { v7 as uuidv7 } from 'uuid';

// Generates time-ordered RFC 9562 UUID:
const orderId = uuidv7();
console.log(orderId);
// Output: 018e4785-3b90-7f2e-831d-b54129b01f92

// Extract millisecond timestamp:
const timeMs = parseInt(orderId.slice(0, 8) + orderId.slice(9, 13), 16);
console.log(new Date(timeMs).toISOString());
๐Ÿš€ HIGH-SPEED BATCH

Bulk Identifier Generation

Generate up to 50,000 unique identifiers simultaneously. Export instantly to Plain Text (`.txt`), JSON Arrays (`.json`), or CSV Column (`.csv`).

items
Previewing generated batch: 10 generated
Developer FAQ & Technical Reference

Frequently Asked Questions

Deep technical explanations covering identifier architecture, token security, cryptographic hashing, and zero-backend client execution.

UUIDs & Identifiers

RFC 9562 & NanoID
01. What is a UUID and what does UUID stand for? +

UUID stands for Universally Unique Identifier (often used interchangeably with GUID, or Globally Unique Identifier). It is a standardized 128-bit algorithmic label formatted as a 36-character hexadecimal string separated by hyphens (e.g., 550e8400-e29b-41d4-a716-446655440000).

As standardized under RFC 9562 (which supersedes RFC 4122), UUIDs empower distributed systems, microservices, and databases to generate uniquely identifying primary keys locally without requiring network synchronization, consensus verification, or a centralized identifier generation authority.

02. What is the difference between UUID v4 and UUID v7? +

The core architectural difference lies in randomness versus time-sortability:

  • UUID v4 is purely pseudo-random, relying entirely on 122 bits of cryptographically secure pseudo-random number generator (CSPRNG) entropy. While completely unpredictable, inserting random v4 keys into relational database engines causes severe B-tree index fragmentation and page splits at massive scales.
  • UUID v7 introduces a revolutionary time-sequential format. It encodes a 48-bit UNIX millisecond timestamp in the most significant bits, followed by monotonic sequence counters and random entropy.

Engineering Recommendation: Deploy UUID v7 for relational database primary keys (PostgreSQL, MySQL, CockroachDB) to maintain lightning-fast chronological B-tree insert indexing, and deploy UUID v4 for transient session authentication IDs, secure bearer tokens, or API secret keys where unpredictability is essential.

03. Can UUIDs collide? Is a UUID completely unique? +

In theoretical mathematics, yes; in practical engineering reality, no. A UUID v4 contains 122 bits of independent entropic variance, creating a total keyspace of 2122 (approx. 5.3 ร— 1036, or 5.3 undecillion) possible combinations.

According to the cryptographic birthday paradox, a system would need to generate approximately 2.71 quintillion UUIDs before reaching a modest 50% probability of a single collision occurring. When generated using hardware-backed operating system entropy (such as the browser native window.crypto.getRandomValues() interface utilized strictly by Modern UUID), cryptographic collision is considered mathematically negligible in production infrastructure.

04. What is a NanoID, and NanoID vs UUID: which is better? +

NanoID is an ultra-compact, URL-safe, high-speed unique identifier generation protocol. When evaluating NanoID vs UUID for architectural integration:

  • Payload Size & Alphabet: NanoID defaults to a concise 21-character representation by harnessing a larger 64-character alphabet (A-Za-z0-9_-). This renders NanoID ~40% smaller than a standard 36-character UUID string while guaranteeing identical cryptographic collision resistance.
  • Execution Performance: NanoID is optimized for rapid hardware memory allocation and CPU efficiency, making it ideal for high-frequency short link URL routing, JSON packet transmission compaction, and NoSQL document keys.
  • Standardization: UUID is explicitly governed by IETF specification protocols (RFC 9562), making it the universal choice for traditional SQL schemas, enterprise RPC contracts, and cross-language interoperability.

Ready to execute these cryptographic utilities locally?

Run multi-format UUID generators, JWT decoders, Bcrypt hashers, and Token synthesis engines inside your browser sandboxโ€”zero server latency, total anti-interception privacy.

Developer Knowledge & Standards

Specifications & Multi-Language Code Snippets.

Integrate UUID version 4, time-ordered version 7 (RFC 9562), and compact NanoIDs directly into your backend or frontend microservices with native, dependency-free code.

generator-snippets.ts
          
        

๐Ÿ“Š Identifier Architecture Matrix

Version Entropy / Logic Ideal Use Case
UUID v4 122 bits random General API keys & universal IDs.
UUID v7 48b time + 74b rand Database Primary Keys (B-Tree sort).
NanoID 126 bits (21 char) URL slugs & tight payloads.
UUID v3/5 MD5 / SHA-1 Hash Deterministic IDs from strings/URLs.
UUID v1 100ns time + MAC Legacy systems requiring MAC audit.
Why use UUID v7 over v4 for databases?

Standard random UUID v4 inserts cause random disk page I/O fragmentation in SQL indexes. Version 7 embeds a chronological millisecond timestamp in the top 48 bits, keeping index inserts naturally sequentially sorted!