UUID / NanoID Generator
Generate UUID v4 instantly using Web Crypto API. Bulk generation for Pro users.
UUID v4
dadbadea-dba3-490b-b4ac-f2edfd97c41cBulk Generation (max 5 on Free plan)
NanoID
C1Y6mPDqEx96udncB19KrUUID v1 Timestamp Decoder
What Is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122 (published 2005) and its successor RFC 9562 (published 2024, which adds UUID versions 6, 7, and 8). UUIDs are designed to be globally unique without requiring a central registration authority — any system can generate one independently with negligible collision risk. They are represented as 32 hexadecimal digits in five groups separated by hyphens, following the pattern xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where the M nibble encodes the version (1–8) and the N nibble encodes the variant (always 8, 9, A, or B for RFC 4122 UUIDs). This canonical string representation is 36 characters, lowercase, and case-insensitive.
UUID v4 (random UUID) is the most widely deployed version. It is generated by filling 122 bits with cryptographically random data (the remaining 6 bits encode the version and variant). With 2^122 ≈ 5.3 × 10^36 possible values, the birthday-paradox collision probability is negligible: you would need to generate approximately 2.71 × 10^18 UUIDs before reaching a 50% probability of any two being equal. For context, if you generated one billion UUIDs per second, you would need over 85 years to reach that threshold. This makes UUID v4 the safe default for database primary keys, session identifiers, file names, correlation IDs, and any context requiring a unique string that can be generated without coordination.
UUID v1 encodes the current timestamp (at 100-nanosecond resolution, counting from October 15, 1582 — the adoption date of the Gregorian calendar) and the MAC address of the generating network interface in the last 12 hex digits. While this construction guarantees both uniqueness (no two machines at the same nanosecond) and temporal ordering, it has two significant drawbacks: the embedded MAC address is a privacy leak that can be used to identify the generating machine or link multiple generated UUIDs to a single device. RFC 9562 introduced UUID v6 as a privacy-preserving, time-ordered replacement for v1, and UUID v7 as the recommended time-ordered UUID for new applications.
NanoID is a modern identifier library (not an IETF standard) created as a compact, URL-safe alternative to UUID. Using a 64-character alphabet (A–Z, a–z, 0–9, _, -) and generating 21 characters by mapping random bytes, NanoID provides collision resistance equivalent to UUID v4 at 21 characters versus UUID's 36, a 42% reduction in string length. This makes NanoIDs attractive for use cases where IDs appear in URLs, are typed by users, or are stored in space-constrained environments. NanoID uses the Web Crypto API's getRandomValues() for secure entropy, the same source used for UUID v4 generation.
How to Use This Generator
- Single UUID — Click "Generate" in the UUID v4 section to create a single cryptographically secure random UUID. The copy icon next to the UUID copies it to your clipboard. A new UUID is generated with each click — every UUID is independently random and not derived from any previous one.
- Bulk Generation — Set the desired count using the number input and click "Generate" in the Bulk section. Free users can generate up to 5 UUIDs at once; Pro users can generate up to 1,000. Each UUID in the list is independently generated using the Web Crypto API. Use "Copy all" to copy the entire list, one UUID per line, ready for pasting into SQL scripts or fixture files.
- NanoID — Click "Generate" to create a compact, URL-safe NanoID using the 21-character, 64-character-alphabet format. NanoIDs are suitable for URL path segments, short user-facing IDs, and any context where the full 36-character UUID format would be too long.
- UUID v1 Timestamp Decoder — Paste any UUID v1 (format: xxxxxxxx-xxxx-1xxx-xxxx-xxxxxxxxxxxx — note the leading 1 in the third group) to extract and display its embedded creation timestamp. This is useful for forensic analysis, debugging legacy systems, or understanding when a UUID was generated.
All UUID and NanoID generation uses the browser's Web Crypto API: crypto.randomUUID() (for UUID v4) and crypto.getRandomValues() (for NanoID and bulk generation). This is the same cryptographic entropy source used for TLS key generation and provides true CSPRNG (Cryptographically Secure Pseudo-Random Number Generation). No data is sent to any server.
How It Works
UUID v4 generation uses crypto.randomUUID(), a native browser API introduced in Chrome 92, Firefox 95, Safari 15.4, and Edge 92. This function generates 128 random bits from the operating system's CSPRNG (on Linux: getrandom() syscall or /dev/urandom; on macOS/iOS: SecRandomCopyBytes; on Windows: BCryptGenRandom), sets the version nibble to 4 (0100 binary) in bits 76–79, sets the variant nibble to 8/9/A/B in bits 64–65, and formats the result as the standard UUID string. For older browsers, a polyfill uses crypto.getRandomValues() with a Uint8Array of 16 bytes and applies the same bit manipulation.
NanoID generation uses a carefully constructed algorithm: crypto.getRandomValues() fills a buffer with random bytes, and each byte is mapped to one of 64 alphabet characters using a bitmask (byte & 63). This ensures a mathematically uniform distribution across all 64 characters — no character is slightly more likely than any other, which would reduce the effective entropy. The resulting 21-character string has log₂(64^21) ≈ 126 bits of entropy, comparable to UUID v4's 122 bits.
The UUID v1 timestamp decoder reconstructs the embedded creation time by parsing the three time-related groups of the UUID string. UUID v1 stores a 60-bit timestamp in a split format: the low 32 bits of the timestamp are in the first UUID group, the next 16 bits are in the second group, and the high 12 bits are in the third group (with the version nibble removed). The decoder reassembles these segments, subtracts the UUID epoch offset (122,192,928,000,000,000 hundred-nanosecond intervals from October 15, 1582 to January 1, 1970), and converts the result to a Unix millisecond timestamp for display.
Use Cases
Database Primary Keys and Distributed ID Generation
UUID v4 as a primary key enables distributed ID generation without a central sequence: each microservice, mobile client, or offline application can create records independently and later sync without conflict. This is especially valuable in offline-first applications, multi-region database replication, and microservice architectures where a central ID generator would be a bottleneck. For PostgreSQL, use the native uuid column type (16 bytes storage) instead of VARCHAR(36) (36 bytes) for a 55% storage reduction and faster index operations.
Test Fixtures, Seed Data, and Migrations
Use bulk UUID generation to produce hundreds of unique IDs for database seed scripts, SQL INSERT statements, test fixture JSON files, or migration scripts. Having deterministic IDs in test fixtures makes tests reproducible across environments. Generate a batch, assign them to test entities in your fixture file, and reference them in related entity foreign keys. Each generated UUID is independently random and guaranteed unique.
Session Tokens, API Keys, and Idempotency Keys
UUID v4's 122 random bits make it resistant to brute-force enumeration attacks — there is no predictable pattern an attacker could exploit. Session tokens, API keys, invitation links, password reset tokens, and OAuth state parameters all benefit from UUID-level randomness. For API idempotency (preventing duplicate charges in payment systems), a UUID v4 as the Idempotency-Key header ensures that even if a request is retried, the server can deduplicate it safely.
File and Resource Naming for Privacy and Collision Avoidance
Name uploaded files, generated reports, cache entries, and temporary resources with UUIDs to avoid two critical problems: (1) filename collisions when multiple users upload files with the same name, and (2) predictable filenames that could expose private documents to unauthorized access (security-by-obscurity, but still a layer of defense). In EU/GDPR contexts, using UUIDs for filenames also avoids embedding user-identifying information (names, IDs) in file paths that may be logged.
Example: UUID v4 in Different Development Contexts
Here is how a UUID v4 is used across common development scenarios — as a database primary key, an API idempotency key, and in Python code generation:
Generated UUID v4:
f47ac10b-58cc-4372-a567-0e02b2c3d479
SQL primary key (PostgreSQL with native uuid type):
CREATE TABLE invoices (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), ...);
INSERT INTO invoices (id, invoice_number, amount)
VALUES ('f47ac10b-58cc-4372-a567-0e02b2c3d479', 'INV-2025-001', 1234.56);
JavaScript API call with idempotency key:
const response = await fetch('/api/invoices', {
method: 'POST',
headers: { 'Idempotency-Key': 'f47ac10b-58cc-4372-a567-0e02b2c3d479' },
body: JSON.stringify(invoiceData)
});
Python (stdlib, no dependencies needed):
import uuid
correlation_id = str(uuid.uuid4())
# => 'f47ac10b-58cc-4372-a567-0e02b2c3d479'UUID v4 is the standard format for unique identifiers across modern web APIs, relational databases, NoSQL stores, and microservice architectures. The 4 in the third group (4372) identifies this as a version 4 UUID; the a (first character of the fourth group, a567) identifies this as a variant 1 UUID per RFC 4122.
Tips & Limitations
Tips
- In PostgreSQL, use the native uuid column type (16-byte storage) and the gen_random_uuid() function instead of a VARCHAR(36) column with application-generated values. This reduces storage by 55% and gives you native UUID comparison operators.
- For high-insert-rate tables (millions of rows per day), UUID v4's random insertion order causes B-tree index fragmentation (each new row inserts at a random position). Use UUID v7 (time-ordered, new in RFC 9562) or ULID for better index locality and range query performance.
- NanoIDs are ideal for URL-safe identifiers in REST API paths, URL shorteners, and any user-facing ID that should be compact. The 21-character length with 64-character alphabet provides ≈126 bits of entropy — essentially the same collision resistance as UUID v4.
- Bulk generated UUIDs are output one per line and can be pasted directly into SQL scripts, CSV import files, or fixture JSON. They can also be piped into database seeding tools that accept line-delimited IDs.
Limitations
- UUID v4 is randomly ordered and therefore not lexicographically sortable by creation time. If you need time-ordered IDs for range scans, use UUID v7 (RFC 9562) or ULID. For PostgreSQL, consider the pgcrypto or pg_ulid extensions.
- UUID v1 potentially exposes the MAC address of the generating machine in the last 12 hex digits. This is a known privacy concern flagged in RFC 4122 itself. Never use UUID v1 in privacy-sensitive contexts — use UUID v4 or UUID v7 instead.
- Free users can generate a maximum of 5 UUIDs at once in bulk mode. A Pro account unlocks bulk generation of up to 1,000 UUIDs per batch.
- NanoIDs are URL-safe but not interoperable with systems that expect the standard UUID hyphenated format (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). If your database schema, API contract, or integration partner expects UUIDs, use UUID v4.
Frequently Asked Questions
Are UUID v4 values truly unique?
In practice, yes — the collision probability is negligibly small for any real application. UUID v4 has 122 random bits (the other 6 bits encode version and variant), yielding 2^122 ≈ 5.3 × 10^36 possible values. By the birthday paradox, you would need to generate approximately 2.71 × 10^18 UUIDs before reaching a 50% chance of a single collision. At a rate of one billion UUIDs per second, that would take over 85 years. The only realistic collision scenario is a broken random number generator — which is why our tool uses the Web Crypto API's CSPRNG rather than Math.random().
Should I use UUID v4 or NanoID for my project?
Use UUID v4 when interoperability matters: if your database schema, API contract, or integration partner expects the standard 36-character hyphenated UUID format, use UUID v4. The format is universally recognized and natively supported in PostgreSQL, MySQL, MongoDB, and most ORMs. Use NanoID when compactness matters: if IDs appear in URLs, are displayed to users, or are stored in space-constrained environments (embedded systems, indexed arrays), NanoID's 21 characters are meaningfully shorter. Both provide equivalent collision resistance.
Should I use UUID v4 as a database primary key?
It depends on your database and insert volume. UUID v4's randomness causes B-tree index fragmentation in RDBMS like PostgreSQL and MySQL because each new row inserts at a random position in the index rather than at the end, leading to page splits and wasted space. For low to moderate insert rates (under ~10,000 rows/second), the fragmentation is negligible. For high insert rates, use UUID v7 (time-ordered, RFC 9562) or ULID — both prepend a millisecond timestamp, making new entries insert near the end of the index like a sequential integer. Always use PostgreSQL's native uuid column type (16 bytes) rather than varchar(36) (36 bytes).
Are the generated UUIDs cryptographically secure?
Yes. Our generator uses crypto.randomUUID() (for UUID v4) and crypto.getRandomValues() (for NanoID and bulk generation) — both part of the W3C Web Cryptography API. These APIs draw entropy from the operating system's CSPRNG: getrandom() on Linux, SecRandomCopyBytes on macOS/iOS, and BCryptGenRandom on Windows. This is the same entropy source used for TLS session key generation — orders of magnitude more secure than Math.random(), which is not cryptographically secure and must never be used for security-sensitive identifiers.
What is the difference between UUID v1, v4, v6, and v7?
UUID v1 (RFC 4122, 2005): timestamp + MAC address. Time-ordered but leaks device identity. Deprecated for new use. UUID v4 (RFC 4122, 2005): 122 random bits. Most widely deployed; not time-ordered. UUID v6 (RFC 9562, 2024): reordered v1 timestamp for lexicographic sortability + random node field (no MAC leak). Drop-in time-ordered v1 replacement. UUID v7 (RFC 9562, 2024): 48-bit Unix millisecond timestamp prefix + 74 random bits. Lexicographically sortable, privacy-preserving, and recommended for new applications needing both uniqueness and time ordering (database PKs, distributed event ordering). UUID v8 (RFC 9562, 2024): custom/experimental layout — application-defined use.
What is a ULID and how does it compare to UUID?
A ULID (Universally Unique Lexicographically Sortable Identifier) is a 26-character identifier using Crockford's Base32 alphabet (0–9 and A–Z excluding I, L, O, U to avoid visual ambiguity). It consists of a 48-bit millisecond timestamp prefix (encodes ~year 2038 range) followed by 80 bits of random data. ULIDs are case-insensitive, URL-safe, and lexicographically sortable — the timestamp prefix ensures that ULIDs generated in sequence sort in creation order, making them excellent for database primary keys. They are not an IETF standard but are widely used in the Node.js ecosystem. For standardized time-ordered identifiers, prefer UUID v7 (RFC 9562).
What is NanoID and how does it compare to UUID v4?
NanoID (github.com/ai/nanoid) is a compact, URL-safe identifier generator using a 64-character alphabet (A–Za–z0–9_-) and Web Crypto API entropy. At 21 characters, NanoID achieves ≈126 bits of entropy (log₂(64^21)), comparable to UUID v4's 122 bits, while being 42% shorter than UUID's 36 characters. NanoIDs are not an IETF standard and do not embed version/variant information. They are not universally recognizable as unique identifiers the way UUIDs are. Use NanoID when compactness and URL safety outweigh interoperability; use UUID v4 for any system that needs to exchange identifiers with external parties.
Can UUID v1 expose my MAC address?
Yes — this is a documented privacy concern in RFC 4122 itself. UUID v1 stores the generating network interface's MAC address in the last 12 hex digits (the node field). Any system that receives a UUID v1 can extract this MAC address and use it to identify the generating machine, correlate multiple generated UUIDs to the same device, or potentially narrow down the physical location of a server. Modern operating systems sometimes use a random node value instead of the actual MAC address to mitigate this, but relying on that behavior is not safe. Use UUID v4 or UUID v7 for all new applications; reserve UUID v1 decoding for forensic analysis of legacy systems.
How do I generate UUIDs in bulk for database seeding?
Use the Bulk UUID Generator section: set the count (Pro: up to 1,000), click Generate, then click Copy all. The output is one UUID per line, suitable for pasting directly into a text file, SQL script, or CSV. For SQL seeding, you can construct INSERT statements by pairing each UUID with other seed data in your editor. Alternatively, most databases provide native UUID generation: PostgreSQL has gen_random_uuid(), MySQL 8 has UUID(), and SQLite can use hex(randomblob(16)) with appropriate formatting.
What is the format of a UUID and how do I validate one?
The standard UUID format is 8-4-4-4-12 hexadecimal digits separated by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version digit (1–8) and N is 8, 9, a, or b (variant). The total length is always 36 characters (32 hex digits + 4 hyphens). To validate a UUID with a regex: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. Many systems also accept UUIDs without hyphens (32 hex digits) or in uppercase — check your target system's requirements. PostgreSQL's uuid type accepts both hyphenated and non-hyphenated forms regardless of case.