UUID Generator Online — UUID v4, v7, ULID & Nano ID

Popular Generators tools

• QR Code GeneratorGenerate QR codes for URLs, Wi-Fi, contacts, events, and more with custom styles.
• Favicon GeneratorGenerate multi-size ICO, SVG, Apple Touch, and PWA favicons from images, text, or emojis.

How to UUID Generator Online

1. 1

   Select your target identifier standard: UUID (v4 random, v7 time-ordered, v1 MAC/timestamp, v6 reordered, Nil, Max), ULID, Nano ID, or CUID2.

2. 2

   Choose your preferred output format: standard lowercase hyphenated (8-4-4-4-12), uppercase HEX, 32-character compact no-dash, curly braces {…}, URN namespace urn:uuid:…, or Base64 binary.

3. 3

   Set your batch count (from 1 to 500 IDs) and select an export separator (newline, comma-separated, formatted JSON array, or space).

4. 4

   Click "Generate" or press ⌘↵ (Ctrl+Enter) to instantly generate unique cryptographic identifiers entirely in browser memory.

5. 5

   Switch to "Validate" mode to verify whether a given string is a valid RFC 9562 UUID, inspect its version nibble, and check variant bitmask conformance.

6. 6

   Switch to "Decode" mode to unpack structural binary fields, extracting UTC timestamps, clock sequence counters, and hardware MAC node octets from time-based UUIDs.

UUID Generator Features

• ✓

  Full RFC 9562 specification compliance: generate, validate, and decode UUID v1, v4, v6, v7, Nil, and Max identifiers.

• ✓

  Time-sortable UUID v7 generation: 48-bit Unix epoch millisecond timestamp combined with 74 bits of random entropy for optimal database B-Tree indexing.

• ✓

  ULID generation: 128-bit Universally Unique Lexicographically Sortable Identifier formatted in 26-character Crockford Base32 notation.

• ✓

  Nano ID generator: compact, URL-safe 21-character cryptographic strings offering 126 bits of entropy with customizable length and character sets.

• ✓

  CUID2 generation: modern collision-resistant identifiers optimized for distributed systems, horizontal scaling, and client-side creation.

• ✓

  High-throughput bulk batch generation: produce up to 500 unique identifiers in a single instantaneous client-side execution.

• ✓

  6 output formats: standard lowercase, uppercase HEX, no-dash 32-hex compact, curly braces {…}, URN urn:uuid:…, and Base64.

• ✓

  Flexible multi-ID export separators: export batches as newline-separated lists, comma-delimited strings, formatted JSON arrays, or space-separated values.

• ✓

  Strict RFC 9562 validator: checks structural formatting, regex syntax, version nibble integrity, and RFC variant bit patterns.

• ✓

  Deep metadata timestamp decoder: parses 60-bit Gregorian (v1/v6) and 48-bit Unix epoch (v7) timestamps to ISO 8601 UTC dates with sub-millisecond precision.

• ✓

  Automatic format heuristic detection: intelligently identifies whether pasted text is a standard UUID, URN, braced UUID, raw 32-hex string, ULID, or Nano ID.

• ✓

  Single-click and keyboard clipboard copy: copy individual rows or export the entire generated batch with ⌘⇧C (Ctrl+Shift+C).

• ✓

  Structural entropy & collision analytics: real-time breakdown of total bit depth, random bits, collision probabilities, and URL safety.

• ✓

  100% client-side zero-retention security: identifiers are generated using the Web Crypto API (crypto.getRandomValues) with zero server transmission.

Supported Formats & Dialects

The UUID Generator supports 6 syntax formats and dialects for accurate parsing and processing.

UUID v4 (RFC 9562 / RFC 4122 Random)

The ubiquitous standard for distributed randomness. Consists of 122 bits of cryptographically secure pseudo-random entropy (CSPRNG), 4 bits of version indicator (0100), and 2 bits of variant indicator (10xx). Formatted as 36 characters in canonical 8-4-4-4-12 hex layout.

UUID v7 (RFC 9562 Epoch Time-Ordered)

The modern gold standard for relational database primary keys. Combines a 48-bit big-endian millisecond Unix epoch timestamp with 74 bits of cryptographically secure random entropy, guaranteeing natural chronological sorting without B-Tree index fragmentation.

UUID v1 & v6 (Gregorian Timestamp & MAC / Reordered)

UUID v1 encodes a 60-bit timestamp in 100-nanosecond intervals since October 15, 1582, alongside a 48-bit IEEE 802 MAC address and 14-bit clock sequence. UUID v6 reorders the timestamp fields most-significant-first to enable B-Tree sortability while retaining v1 compatibility.

ULID (Universally Unique Lexicographically Sortable Identifier)

A 128-bit identifier compatible with UUID storage columns, encoded in 26 Crockford Base32 characters (0-9, A-Z excluding I, L, O, U to prevent visual confusion). Contains a 48-bit millisecond timestamp and 80 bits of randomness, providing case-insensitive monotonic sorting.

Nano ID (URL-Safe Compact Identifier)

A compact, URL-friendly unique identifier utilizing a 64-symbol alphabet (A-Za-z0-9_-). The default 21-character string delivers ~126 bits of cryptographic entropy—equivalent to UUID v4—in a 40% shorter string without requiring URI encoding.

CUID2 (Collision-Resistant Distributed Identifier)

A secure, horizontal-scale identifier algorithm designed for modern distributed applications. Combines process fingerprints, high-precision session counters, system timestamps, and cryptographic hashing to prevent collisions across multi-node microservices.

Frequently Asked Questions

What is RFC 9562, and why did it supersede RFC 4122 for UUID standards?

RFC 9562 is the official IETF standard published in 2024 that updates and replaces RFC 4122. While RFC 4122 only defined UUID versions 1 through 5, RFC 9562 formally standardizes UUID v6 (reordered Gregorian timestamp), UUID v7 (Unix epoch millisecond timestamp + random bits), and UUID v8 (custom vendor formats), alongside standardizing the Nil UUID and Max UUID constants. RFC 9562 addresses modern distributed database requirements where random UUID v4 caused severe B-Tree index fragmentation.

Why is UUID v7 recommended over UUID v4 for database primary keys?

Relational databases (PostgreSQL, MySQL InnoDB, SQLite) index primary keys using B-Tree data structures. Because UUID v4 is completely random, inserting new rows forces the database to write to arbitrary memory pages throughout the index, triggering frequent page splits, high disk I/O, cache thrashing, and index bloat (often 40–50% storage overhead). In contrast, UUID v7 places a 48-bit Unix timestamp at the front of the identifier, ensuring new rows are appended sequentially to the rightmost leaf of the B-Tree index, delivering insertion performance comparable to auto-incrementing integers.

What is the exact internal bit layout of an RFC 9562 UUID v7?

UUID v7 is a 128-bit identifier structured into five distinct fields: 1) unix_ts_ms (48 bits): Unix epoch timestamp in milliseconds (covers dates up to 10889 AD); 2) ver (4 bits): version field set to binary 0111 (0x7); 3) rand_a (12 bits): pseudo-random bits or sub-millisecond counter; 4) var (2 bits): RFC variant bits set to binary 10 (0x8, 0x9, 0xa, or 0xb in hex); and 5) rand_b (62 bits): cryptographically secure pseudo-random entropy. In total, UUID v7 provides 74 bits of randomness.

What are the key trade-offs between ULID and UUID v7?

Both ULID and UUID v7 are 128-bit identifiers featuring a 48-bit millisecond timestamp and monotonic time-sortability. The differences lie in string representation and standardization: ULID is encoded as a 26-character Crockford Base32 string (case-insensitive, URL-safe without hyphens), whereas UUID v7 is an IETF standard formatted as a 36-character hyphenated hexadecimal string (8-4-4-4-12). In database engines with native 16-byte UUID data types (such as PostgreSQL uuid or MySQL BINARY(16)), both occupy identical 16-byte binary storage.

How does Nano ID compare to UUID v4 in collision resistance and length?

A standard 21-character Nano ID uses an alphabet of 64 URL-safe characters (A-Za-z0-9_-), which yields 6 bits of entropy per character (21 × 6 = 126 bits of entropy). This matches the collision resistance of UUID v4 (122 random bits) while producing a string that is 40% shorter (21 chars vs 36 chars) and naturally safe for URL slugs, file paths, and query parameters without percentage encoding.

How does CUID2 guarantee collision resistance in distributed environments?

CUID2 (Collision-Resistant Unique Identifier v2) generates IDs without central coordination by combining four entropy sources: 1) a millisecond timestamp; 2) a monotonic session counter; 3) a unique host/process fingerprint derived from environment variables and system state; and 4) cryptographically strong random salt. These inputs are fed into the SHA-3/Keccak cryptographic hash function to produce a variable-length, collision-resistant string safe for horizontal microservices.

How does UUID v7 maintain monotonic ordering during sub-millisecond generation bursts?

When multiple UUID v7 identifiers are generated within the same millisecond, RFC 9562 permits two implementation strategies: 1) Monotonic Counter: utilizing the 12-bit rand_a field as a sequential counter initialized with random bits and incremented for each subsequent ID within that millisecond; or 2) Pure Randomness: generating fresh 74-bit random values for each ID. Because 74 bits provide 1.89 × 10^22 unique states per millisecond, practical collision probability remains effectively zero even during extreme traffic bursts.

How does UUID decoding extract timestamps and hardware node data?

For UUID v1 and v6, the 60-bit timestamp is extracted from time_low, time_mid, and time_hi fields, converted from 100-nanosecond intervals since October 15, 1582 to Unix epoch milliseconds, while bytes 10–15 reveal the original IEEE 802 MAC address. For UUID v7, decoding parses the leading 12 hexadecimal characters (first 48 bits) directly as a big-endian Unix timestamp in milliseconds. UUID v4 cannot be decoded for timestamps because all 122 payload bits are purely random.

How should UUIDs be stored in PostgreSQL, MySQL, and SQLite databases?

In PostgreSQL, always use the native "uuid" data type, which stores the 128-bit value in compact 16-byte binary format while transparently parsing and rendering hyphenated hex strings. In MySQL (InnoDB), use "BINARY(16)" with UUID_TO_BIN(..., 1) or store raw UUID v7 strings to prevent 36-byte VARCHAR(36) string overhead and keep B-Tree index pages dense. In SQLite, store UUIDs as 16-byte BLOB or 32-character TEXT for maximum indexing throughput.

What are the Nil UUID and Max UUID special constants defined in RFC 9562?

The Nil UUID (00000000-0000-0000-0000-000000000000) is a special 128-bit constant where all bits are set to zero (0x00), commonly used as a null placeholder, default foreign key, or sentinel value in distributed systems. The Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) is defined in RFC 9562 with all 128 bits set to one (0xFF), serving as an upper boundary sentinel for database range queries and sorting algorithms.

Related Developer Tools

• Mock Data GeneratorGenerate realistic fake JSON data from schemas, field templates, or sample data for testing and prototyping.
• Hash GeneratorGenerate and verify cryptographic hashes with multiple algorithms.
• Timestamp ConverterConvert between Unix timestamps, ISO 8601, and human-readable dates instantly.
• Timezone ConverterConvert between time zones and find the best meeting times across cities.
• Password GeneratorGenerate secure passwords, passphrases, and PINs with real-time strength analysis.
• Base64 Encode/DecodeEncode and decode Base64 strings, files, and data URIs instantly.
• Number Base ConverterConvert numbers between binary, octal, decimal, hexadecimal and custom bases.
• Lorem Ipsum GeneratorGenerate placeholder text in multiple formats and styles instantly.
• JWT DecoderDecode, inspect, and validate JWT tokens with claim and signature analysis.