Tip: UUID v4 is random; v7 sorts by time (better for DB indexes). ULID is sortable and URL‑safe. .NET byte arrays differ in endianness for the first 3 fields.
Shortcuts: G generate, C copy, T theme-Client-side only: UUIDs never leave your browser.
About UUID v4 and v7
UUID v4 uses cryptographic randomness (122 random bits after version/variant). UUID v7 is time‑ordered (millisecond timestamp) with additional random bits, improving locality for databases and logs.
Use v4 when you need pure randomness; use v7 when sortability/time locality matters.
Common Uses
Primary keys in distributed databases, request/trace identifiers, idempotency keys, and object identifiers in event logs.
History
UUIDs originated with the Open Software Foundation (DCE). RFC 4122 standardized versions 1, 3, 4, and 5. Version 7 is a newer proposal to improve timestamp ordering while retaining randomness.
UUID v5 deterministically derives an ID from a namespace UUID and a name using SHA‑1. For the same inputs, the output is stable, which is useful for IDs tied to DNS names, URLs, or resource paths.
Common namespaces are defined by the spec (DNS, URL, OID, X.500). You can also use a custom namespace UUID.
Common Uses
Stable identifiers for resources derived from names (e.g., usernames, domains, file paths), deduplicating lookups, cache keys.
History
Namespaced UUIDs (v3/v5) were introduced to enable deterministic IDs using hashing (MD5 or SHA‑1) of a namespace and name pair.
A UUID encodes a version (nibble in the 13th hex digit) and a variant (two most significant bits of the 17th byte). Validators typically check hyphen placement, hex digits, version, and variant bits.
UUID v1 additionally encodes a timestamp (100‑ns since 1582‑10‑15), a clock sequence, and a node identifier.
Common Uses
Sanity checking inputs, validating APIs and forms, enforcing version requirements (e.g., only v4 accepted).
History
Validation patterns emerged alongside widespread UUID adoption in distributed systems, logging, and databases to ensure integrity and interoperability.
ULID is a 128‑bit identifier with a 48‑bit timestamp and a 80‑bit randomness component, represented in Crockford’s Base32. It’s lexicographically sortable and URL‑safe.
UUID encodings: byte arrays differ between RFC/network order and .NET GUID memory layout (mixed endianness in first 3 fields). Base64/Base64URL are standard compact encodings for bytes.
Collisions follow the birthday bound: roughly when the number of samples approaches the square root of the space size.
Common Uses
ULID for sortable IDs; Base64 encoding for compact transport; byte‑order inspection for interop (.NET vs RFC); collision math for capacity planning.
History
ULID emerged in the 2010s to improve sortability and readability over UUIDs; Base64 originates from RFC 1421/2045 and standardized in RFC 4648; birthday collision analysis is a classical probability result.