RFC 4122 LEGACY TIME-BASED SPECIFICATION

UUID v1 Generator (Time-Based & MAC)

Q: 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.

Q: 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.

Q: 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.

Version 1 UUIDs are generated from a 60-bit timestamp representing the number of 100-nanosecond intervals elapsed since the adoption of the Gregorian calendar (October 15, 1582), combined with a 14-bit clock sequence and 48-bit node identifier.

Select Identifier Architecture

Instantaneous zero-latency client switching

TIMESTAMP & NODE MAC

Online UUID Version 1 Generator Tool

Time-based identifier generated from Gregorian calendar epoch timestamp and emulated node MAC address.

Generated Output:

Generating…

Formatting & Manipulation Options

Hyphenation

Character Case

Enclosing Wrappers

Custom Prefix e.g. urn:uuid: or id_

Custom Suffix e.g. -prod or _us-east

Historical Architecture and Gregorian Mathematics of UUID Version 1

Standard Reference: IETF RFC 4122 §4.2 (Originally created under Apollo OS & OSF DCE 1.1)

The 60-Bit Gregorian Epoch Architecture

Unlike modern systems that measure time in Unix seconds (starting Jan 1, 1970 UTC), UUID Version 1 relies on the Gregorian Calendar Epoch: midnight UTC on October 15, 1582. The 60-bit timestamp measures the count of 100-nanosecond intervals (0.1 microsecond ticks) elapsed since that date.

time_low (32 Bits) Lowest 32 timestamp bits

Changes most frequently; occupies the first 8 hex characters of the UUID.

time_mid (16 Bits) Middle 16 timestamp bits

Occupies the second group of 4 hex characters.

time_hi_and_version (16 Bits) Version 1 (0x1...) + 12 bits

Upper 12 timestamp bits prefixed with version binary 0001.

clock_seq & node (64 Bits) 14-bit seq + 48-bit node

Handles backward clock adjustments and host MAC address isolation.

The Hardware MAC Leak & Modern Privacy Safeguards

⚠️ The Melissa Virus & Hardware Leaks

In 1999, the author of the infamous Melissa computer virus was identified and arrested by investigators because the documents contained UUID v1 identifiers embedding his computer's exact physical network card MAC address! Exposing physical hardware addresses poses severe network reconnaissance and geolocation privacy risks.

🛡️ Modern Random Node Protection

Modern UUID implementations (including our online engine) strictly comply with RFC 4122 Section 4.5: the 48-bit node address is generated using cryptographic random bytes with the IEEE 802 multicast bit set to `1`. This guarantees complete privacy protection while maintaining universal uniqueness across distributed instances.

Architectural Comparison: UUID v1 vs. Modern UUID v7

Property	UUID v1	UUID v7 (Recommended)
Timestamp Epoch	Gregorian (Oct 15, 1582)	Unix Epoch (Jan 1, 1970 UTC)
Natural Lexicographical Sorting	❌ No (time_low is placed first)	✅ Yes (Big-endian 48-bit timestamp)
Database Index Efficiency	Poor (causes B-Tree random fragmentation)	Optimal (sequential leaf node appends)

🚀 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`).

Quantity (How Many?) 1 to 50,000

items

Identifier Type

Export Format

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 2¹²² (approx. 5.3 × 10³⁶, 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.

Test JWT Suite Launch Generator

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!