What is the difference between UUID v1, v4, and v5?

UUID v1 is time-based — it combines the current timestamp with the MAC address of the generating machine. This makes v1 UUIDs sequential and traceable to a time and machine, which can be a privacy concern. UUID v4 is random — 122 bits of randomness make collisions virtually impossible without any personal information encoded. UUID v5 is deterministic — given the same namespace and name, it always produces the same UUID, making it useful for creating stable IDs for known entities like URLs or email addresses.

What is the probability of a UUID collision?

For UUID v4, the probability of generating a duplicate is so low it is practically impossible. To have a 50% chance of at least one collision, you would need to generate approximately 2.7 × 10^18 UUIDs — about 45 quadrillion. At a rate of one billion UUIDs per second, it would take 85 years to reach that many. For all practical purposes, UUID v4 collisions are not a concern.

What is the difference between UUID and GUID?

GUID (Globally Unique Identifier) is Microsoft's term for the same concept as UUID. They follow the same RFC 4122 specification and are interchangeable. The term UUID is more common in open-source and cross-platform contexts; GUID is used in Windows/.NET ecosystems.

Should I store UUIDs as text or binary in a database?

Binary storage (16 bytes) is more efficient than text storage (36 characters as a string). Most databases support a UUID or BINARY(16) column type that stores UUIDs in binary format while presenting them in standard string format in queries. For PostgreSQL, use the native uuid type. For MySQL, use BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID() functions. Text storage works fine for smaller tables where the performance difference is negligible.

How to Generate a UUID Online

Generate RFC 4122 compliant UUIDs instantly with our free UUID Generator. Choose between UUID v1, v4, and v5 formats in bulk.

Steps

Choose UUID version

Select the UUID version you need. Version 4 (random) is the most common choice for generating unique IDs in databases and APIs — it uses random numbers and has an astronomically small collision probability. Version 1 (time-based) includes a timestamp and MAC address. Version 5 (namespace + name) generates a deterministic UUID from a namespace and input string.

Set quantity

Enter how many UUIDs to generate. You can generate 1 to 1000 at once. Bulk generation is useful when seeding databases, creating test fixtures, or pre-allocating IDs for an import job.

Choose format options

Select uppercase or lowercase output. Choose whether to include hyphens (standard: 550e8400-e29b-41d4-a716-446655440000) or output as a compact string without hyphens (550e8400e29b41d4a716446655440000). Some systems require the compact format.

Click Generate

Click the Generate button to produce your UUIDs. They appear in the output area, one per line.

Copy the results

Click Copy All to copy all generated UUIDs to your clipboard, or click individual UUIDs to copy them one at a time. For bulk use, the newline-separated output can be piped directly into scripts or imported into spreadsheets.

Why UUIDs Are Used as Database Primary Keys

Traditional auto-incrementing integer primary keys (1, 2, 3...) are simple but have significant limitations in distributed systems. They expose information about record count and creation order to anyone who sees the ID. They require coordination between database shards to avoid duplicates. They make it difficult to pre-generate IDs before a record is inserted, which complicates offline-first apps and event sourcing architectures. UUIDs solve all these problems: they can be generated client-side without a database round-trip, they do not leak business information, and they work in distributed systems without coordination. The tradeoff is that random UUIDs (v4) cause index fragmentation in B-tree indexes because new rows insert at random positions rather than at the end. UUID v7, a newer variant, addresses this by including a timestamp prefix to make UUIDs monotonically increasing like auto-increment IDs.

UUID v5 for Deterministic ID Generation

UUID v5 generates the same UUID every time you provide the same namespace and name, using SHA-1 hashing internally. This is powerful for scenarios where you need a stable, unique identifier for a known entity. For example, you could generate a UUID v5 for every URL in your system using the URL namespace — the URL 'https://example.com/page' will always hash to the same UUID. This lets you create foreign key relationships without storing the original URL as a key. It is also useful for deduplication: if you are importing records from multiple sources and the same entity appears in both, generating UUID v5 from the entity's natural key means duplicates produce the same UUID and can be detected automatically.

UUID Alternatives: ULID, NanoID, and Snowflake IDs

While UUID v4 is the most widely used unique identifier format, alternatives exist for specific use cases. ULID (Universally Unique Lexicographically Sortable Identifier) combines a 48-bit millisecond timestamp with 80 bits of randomness, making ULIDs sortable by creation time — solving the index fragmentation problem of UUID v4 while remaining URL-safe. NanoID generates shorter unique IDs using a custom alphabet (default 21 characters) with collision resistance equivalent to UUID v4, useful when you need compact IDs for URLs or user-facing identifiers. Snowflake IDs (used by Twitter and Discord) are 64-bit integers combining timestamp, machine ID, and sequence number — extremely compact and sortable but requiring a centralised ID generation service. Choose the format that best matches your storage, sorting, and readability requirements.