Uuid Generator

• Math.random() vs Crypto: Math.random() is not cryptographically secure. An attacker can predict future outputs if they observe enough generated numbers. True UUID v4 generation must rely on crypto.getRandomValues() to ensure unpredictable entropy.
• Information Leakage: UUID v1 uses the MAC address of the generating computer and the exact time. This can unintentionally leak the physical machine identity of the creator, which is why v4 or v7 are preferred today.

Using a random UUID v4 as a Primary Key in a SQL database (like PostgreSQL or MySQL) can cause severe fragmentation in B-Tree indexes. Since the IDs are inserted in a random order, the database must constantly split pages on disk.

UUID v7 solves this by placing a timestamp at the start of the ID. New IDs are always "greater" than old IDs, allowing sequential, append-only disk writes that vastly improve insert performance.

• Web Crypto API: Uses window.crypto.randomUUID() when available, which natively relies on the OS-level entropy pool (e.g., /dev/urandom) to generate secure v4 UUIDs.
• Bitwise Operations: For v7, this tool manually manipulates 8-bit unsigned integer arrays (Uint8Array) to splice the current epoch time into the random byte array.

• RFC 4122: The original standard defining UUIDs.
• RFC 9562: The updated 2024 standard that officially introduces time-ordered UUIDs like v7.

Common mistakes when implementing UUIDs:

• Insufficient Entropy: Using a polyfill that falls back to Math.random() if the Crypto API is unavailable, dramatically increasing the risk of collisions.
• Collisions in v4: The chance of a collision is astronomical. You would need to generate 1 billion UUIDs per second for 85 years to have a 50% chance of a single collision.