UUID FAQ

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify information in computer systems. It is represented as 32 hex digits in the format 8-4-4-4-12. UUIDs are standardised by RFC 9562 and designed to be globally unique without a central registration authority.

Nothing — they are identical. GUID (Globally Unique Identifier) is simply Microsoft's name for UUID. Both use the same 128-bit format, follow RFC 9562, and are completely interchangeable. Microsoft uses the term in .NET, Windows APIs, and SQL Server.

There are 2¹²⁸ possible UUIDs — approximately 340 undecillion (340 × 10³⁶). For UUID v4 specifically, 122 bits are random, giving 2¹²² ≈ 5.3 × 10³⁶ unique values. Collisions are negligible in practice.

v4 for general use (session tokens, API keys, most IDs). v7 for database primary keys (time-ordered, index-friendly). v5 for deterministic IDs from known data. Avoid v1 in new systems — v7 is strictly better.

UUID v4 is random, causing index fragmentation in clustered B-tree indexes (MySQL InnoDB, SQL Server). New rows are inserted at random positions, causing page splits and poor cache performance. UUID v7 is time-ordered — it inserts at the end of the index like an auto-increment integer, giving the same performance while retaining UUID benefits.

The Nil UUID is 00000000-0000-0000-0000-000000000000 — all 128 bits zero. It is defined in RFC 9562 and used as a null/empty identifier placeholder, similar to null in programming. Never use it as a real entity identifier.

Yes. UUIDCore uses crypto.getRandomValues() (Web Crypto API) — a cryptographically secure random number generator. All generation happens in your browser. Nothing is transmitted to our servers.

No. With 122 bits of cryptographic randomness, UUID v4 cannot be practically predicted or brute-forced. This is true only when generated using a CSPRNG — never use Math.random() for UUID generation in production.

Yes — UUID v4 is safe to expose in URLs. Unlike sequential integers, random UUIDs prevent enumeration attacks. Ensure your access control validates permissions — the UUID itself is not an access control mechanism.

Use the native UUID type — it stores as 16 bytes (more efficient than VARCHAR(36)). For v4: DEFAULT gen_random_uuid(). For v7: use the pg_uuidv7 extension or generate in application code.

Store as BINARY(16) for best performance. Use UUID_TO_BIN(uuid, 1) to insert and BIN_TO_UUID(col, 1) to retrieve. The 1 flag swaps the byte order for better index performance. Avoid VARCHAR(36) — it uses 2× the storage.

Use UUID when: IDs are generated client-side, you merge data from multiple databases, you want to prevent enumeration, or you are building distributed systems. Use auto-increment when: single database, maximum index performance, no need for global uniqueness. A popular hybrid: UUID as public API identifier, auto-increment as internal primary key.

Use the 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. Or use our UUID Validator tool which also identifies the version and variant.

RFC 9562 is the current IETF UUID standard, published May 2024. It supersedes RFC 4122 and adds UUID versions 6, 7, and 8 while clarifying existing versions 1–5. All UUIDs generated by UUIDCore conform to RFC 9562.

Both are name-based and deterministic, but v3 uses MD5 (cryptographically broken) and v5 uses SHA-1. Always prefer UUID v5 over v3. Neither should be used as a cryptographic security mechanism — they are for generating reproducible identifiers, not secure tokens.