UUID vs GUID: What They Are and How to Generate Unique IDs

Every modern application eventually needs to generate unique identifiers — for database rows, API resources, file uploads, session tokens. UUIDs (Universally Unique Identifiers) are the industry-standard answer, built into every major language and database. This guide explains the format, the different versions, the UUID vs. GUID naming confusion, how to generate them in code, and when a simpler alternative might serve you better.

UUID Format: 128 Bits, 32 Hex Characters

A UUID is a 128-bit number displayed as 32 hexadecimal characters grouped into five sections separated by hyphens:

550e8400-e29b-41d4-a716-446655440000
^^^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^
8 chars  4    4    4    12

The groups are conventionally written as 8-4-4-4-12. The total is 32 hex digits = 128 bits. The third group encodes the UUID version in its first digit (the 4 in the example above signals UUID version 4). The first digit of the fourth group encodes the variant (almost always 8, 9, a, or b in modern UUIDs).

UUIDs are case-insensitive. 550E8400-E29B-41D4-A716-446655440000 and 550e8400-e29b-41d4-a716-446655440000 are the same identifier. Lowercase is the convention in most ecosystems.

UUID vs. GUID: Same Thing, Different Brand

GUID stands for Globally Unique Identifier and is Microsoft's name for essentially the same standard. Microsoft introduced GUIDs in the early COM/OLE infrastructure in the 1990s, and the term stuck in Windows and .NET development. When a .NET developer says "GUID" and a Linux developer says "UUID," they are describing identifiers generated from the same RFC 4122 specification.

There is one minor practical difference: Microsoft's GUID format wraps the value in curly braces in some contexts — {550e8400-e29b-41d4-a716-446655440000} — while standard UUID representation does not. When exchanging identifiers between systems, strip the braces if present.

UUID Versions Explained

RFC 4122 defines several UUID versions. Three are relevant in modern development.

Version 1 — Time and MAC Address

UUID v1 encodes the current timestamp (in 100-nanosecond intervals since October 1582) and the MAC address of the generating machine. The result is time-ordered and unique across machines. The downside is significant: it leaks the MAC address of the server that generated it and the exact time of creation. This is a privacy concern when UUIDs are exposed in URLs or APIs. UUID v1 is largely superseded by v7 for time-ordered use cases.

Version 4 — Random

UUID v4 is 122 bits of cryptographically random data (the remaining 6 bits are reserved for version and variant flags). It has no structure, encodes no information, and requires no coordination between generators. This simplicity makes it the most widely used version by a large margin. It is the default in most UUID libraries and the version generated by crypto.randomUUID() in browsers and Node.js.

Version 7 — Time-Sortable (Recommended for Databases)

UUID v7 is a newer addition that combines the best of v1 and v4. The first 48 bits encode a Unix millisecond timestamp, making v7 UUIDs lexicographically sortable by creation time. The remaining bits are random. This is extremely valuable for database primary keys: because v7 UUIDs are roughly sequential, they cause far less B-tree index fragmentation than random v4 UUIDs. If you are using UUIDs as primary keys in PostgreSQL, MySQL, or similar databases, v7 is the version to use in new systems.

Generating UUIDs in Code

JavaScript / Node.js (v4, no dependency):

// Browser and Node.js 19+
const id = crypto.randomUUID();
console.log(id);
// "550e8400-e29b-41d4-a716-446655440000"

// Node.js (all versions)
const { randomUUID } = require('crypto');
console.log(randomUUID());

JavaScript with the uuid package (v1, v4, v7):

npm install uuid

import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';

console.log(uuidv4()); // random
console.log(uuidv7()); // time-sortable

Python:

import uuid

# UUID v4 (random)
print(uuid.uuid4())
# 550e8400-e29b-41d4-a716-446655440000

# UUID v1 (time + MAC — avoid exposing in public APIs)
print(uuid.uuid1())

# UUID v4 as a string without hyphens (common for database storage)
print(str(uuid.uuid4()).replace('-', ''))

PostgreSQL:

-- Built-in since PostgreSQL 13
SELECT gen_random_uuid();

-- As a default column value
CREATE TABLE users (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  email TEXT NOT NULL
);

MySQL:

-- Built-in UUID() function generates v1
SELECT UUID();

-- For v4-style random UUIDs in MySQL 8.0+
-- Use a generated column or application-level generation
-- MySQL does not have a built-in random UUID function

Collision Probability: Effectively Zero

A common question: can two independently generated UUID v4 values ever be the same? Technically yes. Practically, no.

UUID v4 has 122 random bits, giving approximately 5.3 × 10³⁶ possible values. To have a 50% probability of a single collision, you would need to generate roughly 2.7 × 10¹⁸ UUIDs — about 2.7 quintillion. If your application generated one million UUIDs per second, it would take roughly 85 years to approach that threshold.

For any practical application, UUID v4 collisions are a non-issue. If your system genuinely requires provably unique IDs (e.g., cryptographic nonces), use a cryptographic random number generator directly rather than relying on UUID structure.

When NOT to Use UUIDs

UUIDs are excellent identifiers, but they are not always the right choice. Here are situations where alternatives are worth considering:

High-performance database primary keys with sequential access patterns. Random v4 UUIDs are 128 bits and non-sequential, which causes index fragmentation in B-tree indexes. For write-heavy tables with billions of rows, auto-incrementing 64-bit integers (BIGSERIAL in PostgreSQL, BIGINT AUTO_INCREMENT in MySQL) are measurably faster. UUID v7 is a middle ground — time-sortable UUIDs behave much more like sequential integers for index performance.
URLs where brevity matters. A UUID is 36 characters with hyphens. If you need a short, URL-safe ID, Base64-encoded random bytes (e.g., 16 bytes → 22 characters) or a library like nanoid produce shorter identifiers with equivalent uniqueness guarantees.
Sharded or distributed databases with their own ID schemes. Systems like Snowflake IDs, Twitter's Snowflake, or MongoDB's ObjectID encode timestamp and machine ID in a compact format specifically designed for distributed environments at scale. At very high throughput, these purpose-built schemes outperform generic UUIDs.
Simple single-instance applications. If you have one server, one database, and no distributed systems concerns, auto-incrementing integers are simpler, smaller, and faster. Use UUIDs when you need global uniqueness across systems.

Generate UUIDs in Bulk Online

When you need a batch of UUIDs for test data, seed scripts, or one-off migrations, the DevToolbox UUID Generator lets you generate up to 10,000 UUIDs at once and export them as CSV or plain text. Choose v4 for random IDs or v7 for time-sortable IDs. Everything runs client-side — no UUIDs are logged or stored server-side.

Summary

UUID and GUID refer to the same 128-bit identifier standard; GUID is simply Microsoft's terminology. UUID v4 (random) is the right default for most use cases — it is simple, privacy-safe, and available natively in every major language without a library. UUID v7 (time-sortable) is the better choice when UUIDs serve as database primary keys, because their sequential ordering dramatically reduces index fragmentation at scale. For the vast majority of applications, UUID v4 collision probability is mathematically negligible and can be ignored in practice.