UUID generieren
UUID Generator produces cryptographically random v4, time-ordered v7 and Gregorian-timestamp v1 identifiers in bulk, using the browser's own crypto API. It also inspects an existing UUID to report its version, variant and embedded timestamp. No identifier is ever sent anywhere.
Die Oberfläche dieses Tools ist auf Englisch.
Die folgende Anleitung ist nur auf Englisch verfügbar.
What is a UUID, and how do v1, v4 and v7 differ?
Universally Unique Identifiers (UUIDs), also standardized by the Open Software Foundation (OSF) and ISO/IEC 9834-8:2005 as Globally Unique Identifiers (GUIDs), are 128-bit numerical labels engineered to enable distributed software architectures to generate primary keys and entity references without requiring synchronization through a centralized registry or database authority. For nearly two decades, the fundamental standard governing UUID generation was RFC 4122, published in July 2005. In May 2024, the Internet Engineering Task Force (IETF) published RFC 9562, a major overhaul that obsoleted RFC 4122 and officially introduced time-ordered UUID versions tailored to modern high-throughput databases and distributed streaming pipelines.
Binary Anatomy and Layout of a 128-Bit UUID
Regardless of the version, every canonical UUID is represented in textual form as 32 hexadecimal digits displayed in five hyphen-separated groups with the format 8-4-4-4-12, totaling 36 characters (including the 4 hyphens):
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
├───────┼────┼────┼────┼────────────┤
time_low time_mid time_hi clock_seq node
M = 4-bit Version Indicator (0x1 = v1, 0x4 = v4, 0x7 = v7)
N = Variant field (Bits 10xx correspond to RFC 4122 / RFC 9562; characters 8, 9, a, or b)
UUID Version 4: Pure Cryptographic Entropy
UUID v4 is completely pseudo-random. Out of the 128 bits comprising the identifier, 4 bits are reserved to encode the version (0b0100) and 2 bits are reserved to encode the variant (0b10). This leaves exactly 122 bits of cryptographically secure entropy.
The total number of possible UUID v4 identifiers is 2¹²² ≈ 5.3 × 10³⁶. To comprehend the astronomical magnitude of this space, consider that if every human on Earth generated one billion UUIDs every second for the next century, the likelihood of a single duplicate occurring remains under one in a billion. However, this total randomness comes at a steep architectural cost when utilized as primary keys within persistent storage engines.
The Database Indexing Crisis and the Rise of UUID v7 (RFC 9562)
Relational databases (such as PostgreSQL, MySQL, and SQLite) and document stores organize primary keys in B-Tree (Balanced Tree) or LSM-Tree index structures. In a B-Tree, keys are stored in sorted, sequential order across fixed-size disk pages (typically 8 KB or 16 KB). When consecutive inserts have sequential or monotonic keys (such as standard auto-incrementing integers), each new insert appends cleanly to the right-hand leaf node. The index pages remain fully saturated, cache lines stay hot, and disk write amplification is minimal.
When UUID v4 is used as a primary key, each generated value lands at a completely random location in the B-tree keyspace. As the index grows beyond RAM capacity:
- Every single insert requires reading a random 8 KB index page from disk into the buffer cache.
- Existing index pages become full and undergo costly page splits, creating 50% empty space and fragmenting disk storage.
- Database cache hit ratios plummet from >99% to <20%, bottlenecking transactional throughput (IOPS).
UUID v7 directly resolves this dilemma. It structures the 128 bits into three deliberate tiers:
- 48-Bit Unix Epoch Timestamp: The most significant 48 bits encode the current Unix timestamp in milliseconds. This timestamp will not overflow until the year 10889 AD.
- 12-Bit Sub-millisecond / Sequence Counter: Provides sub-millisecond precision or monotonic sequence incrementation, guaranteeing strict chronological sorting even when thousands of records are generated in the same millisecond on the same thread.
- 62-Bit Cryptographic Entropy: Provides 62 bits of CSPRNG randomness, guaranteeing absolute collision immunity across globally distributed clusters.
With UUID v7, database systems achieve the best of both paradigms: sequential B-tree append performance matching 64-bit integers, combined with the distributed generation capability and security of UUIDs.
UUID Version 1: The Legacy Gregorian Standard
UUID v1 was the original time-based UUID defined in RFC 4122. It encoded a 60-bit timestamp counting 100-nanosecond intervals since October 15, 1582 (the date the Gregorian calendar was instituted by Pope Gregory XIII). However, v1 suffered from two significant design liabilities:
- End-endianness and Field Inversion: The least significant 32 bits of the timestamp (
time_low) were placed at the very beginning of the UUID string. Consequently, consecutive v1 UUIDs did not sort chronologically without byte reordering (which later motivated the experimental UUID v6). - Hardware MAC Leakage: The final 48 bits embedded the physical IEEE 802 MAC address of the host machine. This allowed adversaries to reconstruct the identity and physical location of the server that authored the UUID, creating severe information disclosure vulnerabilities.
RFC 9562 formally recommends that new designs adopt UUID v7 in place of UUID v1.
Which keyboard shortcuts does the UUID generator support?
Frequently asked questions
Why is UUID v7 recommended over UUID v4 for database primary keys?
UUID v4 values are entirely random across all 122 entropy bits. When inserted as primary keys into clustered database indexes (such as PostgreSQL B-Trees or MySQL InnoDB clustered indexes), random keys force frequent page splits, catastrophic cache eviction, and random I/O write amplification. UUID v7 (RFC 9562) solves this by encoding a 48-bit Unix millisecond timestamp at the beginning of the identifier. This guarantees chronological monotonicity, allowing new rows to append sequentially to the rightmost index pages like an auto-incrementing integer, while retaining global uniqueness across distributed nodes without coordination.
What is the mathematical collision probability of UUID v4?
A standard UUID v4 contains 122 bits of pseudo-random entropy (6 bits are reserved for version and variant). The probability of at least one collision among n generated UUIDs is approximated by the birthday problem formula: p ≈ 1 - exp(-n² / (2 × 2¹²²)). To achieve even a one-in-a-billion (10⁻⁹) probability of a single collision, a system would need to generate over 103 trillion UUIDs. Generating one billion UUIDs per second for 100 years would still yield a negligible collision likelihood.
How are UUIDs generated securely without contacting a server?
All UUIDs are generated locally in your browser using the Web Cryptography API (crypto.randomUUID and crypto.getRandomValues). These native browser APIs interface directly with your operating system's kernel cryptographic entropy pool (such as /dev/urandom on Linux and macOS, or CryptGenRandom / BCryptGenRandom on Windows). No data is ever transmitted across any network.
Why was UUID v1 superseded, and how is its timestamp encoded?
UUID v1 encoded a 60-bit count of 100-nanosecond intervals since the start of the Gregorian calendar reform on October 15, 1582. However, its last 48 bits were originally designed to embed the physical MAC address of the network interface card. This posed serious privacy and security risks by leaking hardware identifiers and machine locations into public URLs and databases. UUID v7 obsoleted v1 by replacing the complex Gregorian offset with clean Unix Epoch milliseconds and replacing MAC addresses with secure random bits.
Can I generate thousands of UUIDs at once for seed data?
Yes. The bulk generator supports generating up to 5,000 UUIDs per batch in a split second. You can customize casing, hyphenation, quotation marks, curly braces, and output delimiter formats including newline, comma-separated lists, and valid JSON arrays.
Are these UUIDs safe to use as security tokens?
A v4 UUID carries 122 random bits from the browser's cryptographic generator, which is strong enough as a value — but a UUID is not designed to be a secret: they end up in URLs, logs and support tickets. For session tokens or password resets, use something your server issues and can revoke. v1 and v7 are explicitly not secrets, because both encode the time at which they were made.