Online UUID & GUID Generator

A UUID generator is an algorithm-driven tool or software library that creates 128-bit Universally Unique Identifiers according to specifications established by the Internet Engineering Task Force (IETF) in RFC 4122 and the modern RFC 9562.

Its primary purpose is to produce identifiers that are mathematically guaranteed to be unique across all devices, servers, and networks worldwide without needing a central database or coordination server to verify whether an ID is already in use.

Modern browser-based tools, such as this online UUID generator, use the cryptographically secure crypto.getRandomValues() Web Crypto API to guarantee true cryptographic randomness with 100% client-side privacy.

You can create a UUID instantly across multiple environments:

• Online (Zero Setup): Use the generator on this page to create single or bulk UUIDs (up to 5,000 at once) in formats like v4, v7, or v1 with customized casing, braces, and output formats.
• JavaScript & TypeScript: In modern browsers and Node.js (v14.17+):

  const myUuid = crypto.randomUUID();

• Python: Using the standard library:

  import uuid
  print(uuid.uuid4()) # Random v4
  # Or time-ordered v7 in Python 3.14+ / uuid6 package

• Command Line (Linux / macOS): Run uuidgen in your terminal.
• SQL Databases: In PostgreSQL use SELECT gen_random_uuid(); and in MySQL 8.0+ use SELECT UUID();.

UUID stands for Universally Unique Identifier. It is an internationally recognized standard defined by ISO/IEC 9834-8 and the IETF (RFC 4122 and RFC 9562).

A UUID is a 128-bit number represented as 32 hexadecimal characters broken into five groups by hyphens (format: 8-4-4-4-12), for a total of 36 characters.

In Microsoft ecosystems, the same concept is called a GUID (Globally Unique Identifier). Both represent the identical 128-bit data structure.

Software engineers and database architects use UUIDs for four critical reasons:

1. Decentralized Generation: Multiple application instances, worker threads, or distributed microservices can generate unique IDs concurrently without making network calls to a central database sequence.
2. Security & Preventing Enumeration: Sequential IDs (like /user/104, /order/105) expose business metrics to competitors and enable Insecure Direct Object Reference (IDOR) attacks. UUIDs are unpredictable and non-sequential.
3. Seamless Merging & Sharding: When combining records from multiple database shards, regional datacenters, or staging environments, UUID primary keys never collide.
4. Offline & Mobile-First Reliability: Mobile apps and client browsers can generate valid IDs while offline and push records to the cloud later without primary key remapping.

You can identify a UUID by inspecting its structure and character positions:

• Standard Format: Exactly 36 characters containing 32 hexadecimal digits and 4 hyphens placed after characters 8, 12, 16, and 20.
• Version (V): The 13th character (first digit of the 3rd block). A 4 means UUIDv4 (random), 7 means UUIDv7 (time-ordered), and 1 means UUIDv1.
• Variant (A): The 17th character (first digit of the 4th block). In RFC 4122 and RFC 9562 standard UUIDs, this character is always 8, 9, a, or b (representing binary pattern 10xx).

You can paste any string into our UUID Inspector to immediately dissect its version, variant, and timestamps.

In pure mathematical theory, yes—because the total number of permutations is finite (2¹²² for UUIDv4). However, in practical engineering reality, no two properly generated UUIDs will ever collide.

Here is the probability breakdown:

• UUIDv4 contains 122 bits of cryptographic entropy, giving 5.3 × 10³⁶ possible values.
• To reach just a 50% chance of a single duplicate (due to the Birthday Paradox), you would have to generate approximately 2,710,000,000,000,000,000 (2.71 quintillion) UUIDs.
• If you generated 1 billion UUIDs per second non-stop for 85 consecutive years, the probability of finding a single duplicate is less than one in a billion.

Collisions only occur in practice if software uses broken or pseudo-random number generators with bad seeding instead of cryptographically secure random sources.

"ID" (Identifier) is an umbrella term for any label that distinguishes an entity. A UUID is a specific, standardized type of ID:

Engineers choose UUIDs over standard numeric IDs in modern web applications for several advantages:

• Prevents Business Intelligence Leaks: If an invoice URL is /invoice/500 and tomorrow it is /invoice/550, competitors can deduce your exact daily order volume. A UUID reveals nothing about your sales numbers or customer count.
• Stops Insecure Direct Object References (IDOR): Attackers cannot iterate through IDs by incrementing numeric parameters (?id=101, ?id=102).
• Decentralized Scale: You don't have to bottleneck writes on a single master database holding an AUTO_INCREMENT lock.
• Optimistic Client UIs: Frontends can generate a UUID locally, immediately display the newly created item, and sync it to the backend asynchronously.

Tip: For database primary keys where index performance is crucial, use UUIDv7 instead of UUIDv4 to preserve sequential B-Tree ordering.

The total theoretical capacity of the 128-bit UUID address space is:

For UUIDv4, 6 bits are fixed (4 bits for version, 2 bits for variant), leaving 122 bits of variable entropy:

To visualize this scale: if every person on Earth generated 1 million UUIDs every second, it would take more than 20 billion years to exhaust the namespace.

Whether you can decode a UUID depends entirely on the version you are inspecting:

• UUIDv7 (Decodable): The first 48 bits encode a Unix epoch timestamp in milliseconds. You can extract the exact date, hour, minute, second, and millisecond the UUID was generated.
• UUIDv1 & UUIDv6 (Decodable): Encodes a 60-bit Gregorian calendar timestamp (in 100-nanosecond increments since 1582) and historically a hardware MAC address or simulated node ID.
• UUIDv4 (Cannot be decoded): Aside from the 4-bit version marker (4) and 2-bit variant (10xx), the remaining 122 bits are random noise. There is no timestamp, author, or encoded payload to decrypt or reverse.

Try our UUID Inspector to inspect any UUID in real time and decode its metadata.

The length of a UUID depends on the representation:

While UUIDs are powerful, avoid them in these scenarios:

• UUIDv4 in Clustered B-Tree Indexes: Random UUIDv4 keys cause page splits and severe index fragmentation in databases like PostgreSQL, MySQL InnoDB, and SQLite. Solution: Use modern time-ordered UUIDv7 instead.
• Tight Storage & RAM Constraints: In multi-billion row tables, 16-byte UUIDs (and their secondary indexes) consume double to quadruple the memory of 4-byte or 8-byte integers.
• Human-Facing URLs & Codes: 36-character UUIDs are terrible for users to memorize, type, or speak. Use short alphanumeric IDs (like NanoID, Sqids, or ULIDs) for customer-facing order numbers or invite links.
• Simple Single-Database Apps: If an application has a single monolithic database that never shards or shares IDs with external systems, standard sequential integers remain simpler and faster.

Here is a canonical example of a Version 4 UUID:

Component Breakdown:

• f47ac10b (8 hex characters / 32 bits): Low bits of random entropy.
• 58cc (4 hex characters / 16 bits): Mid bits of random entropy.
• 4372 (4 hex characters / 16 bits): The first digit 4 specifies Version 4.
• a567 (4 hex characters / 16 bits): The first digit a specifies the RFC 4122/9562 variant (binary 1010).
• 0e02b2c3d479 (12 hex characters / 48 bits): Node bits of random entropy.

Compare this to a UUIDv7 example: 018e69df-25b7-789a-b42a-4318c4cf33a5, where the first 48 bits (018e69df-25b7) represent the exact millisecond timestamp.