A UUID (Universally Unique Identifier) is a 128-bit value used to label records, files, sessions and API objects so they stay distinct across machines without a central ID server.
A UUID (Universally Unique Identifier) is a 128-bit value used to label records, files, sessions and API objects so they stay distinct across machines without a central ID server. Microsoft systems often call the same idea a GUID. The usual text form is 32 hexadecimal digits in five groups: 8-4-4-4-12, for example 550e8400-e29b-41d4-a716-446655440000.
UUIDs are identifiers, not secrets. Version 4 is almost entirely random; version 7 embeds a Unix millisecond timestamp and sorts well in databases; version 1 is an older time-and-node design. The current standard is RFC 9562, which updates the classic RFC 4122 rules. For a short glossary entry, see MDN's UUID page.
Generate random v4 values in the browser with the free UUID generator on mfaysal.com. This guide covers the layout, the main versions, the collision myth, when v4 beats v7 (and the reverse), and when you should not treat a UUID as a password or API key.
Contents
A UUID is 128 bits of structured data. Systems store those bits in binary columns or as a 36-character string with hyphens (32 hex digits plus four hyphens). Some APIs drop the hyphens; some wrap the value in braces. The underlying 128 bits are what matter for uniqueness.
The point of a UUID is distributed uniqueness. Two laptops, two data centres or two offline mobile apps can mint IDs without calling a shared counter service. That property makes UUIDs popular as primary keys, idempotency keys, upload names, log correlation IDs and object references in public APIs.
UUIDs are not magic. Uniqueness depends on the version rules and on good randomness (for v4 and the random fields in v7). A buggy generator that always returns the same bytes will collide every time. A correct generator following the RFC will collide so rarely that most teams never see it in practice.
Canonical output is lowercase hex. Parsers should accept uppercase too. RFC 9562 recommends lowercase when you serialise. Treat string compare as case-insensitive if your stack might mix cases from different libraries.
People sometimes say "UUID" when they mean any random token. That is imprecise. A UUID has a fixed size, a version nibble, a variant field and a defined layout. A 64-bit snowflake ID or a 256-bit random API key is a different tool with different trade-offs.
Because the format is standardised, almost every major language ships a UUID library. You rarely need to hand-roll bit packing. Prefer the platform generator that documents which RFC version it emits.
In the common string form, the third group starts with the version digit and the fourth group starts with the variant. For a version-4 UUID you will see a 4 at the start of the third group and 8, 9, a or b at the start of the fourth.
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
^ ^
| variant (RFC 4122/9562)
version (1–8)Those fixed bits carve a few values out of the 128-bit space so receivers can tell versions apart. Version 4 therefore has 122 random bits, not 128. Version 7 places a timestamp in the high bits and fills most of the rest with random data (plus the same version and variant markers).
Variant bits mark the RFC family. You do not normally set them by hand; libraries do. If you parse UUIDs yourself, reject values with an unexpected variant before you trust the version field.
Binary storage is 16 bytes. Text storage is longer. Databases such as PostgreSQL offer a native uuid type that stores the compact form and still accepts the hyphenated string on input. Storing only the 32 hex digits without hyphens is fine if every client agrees; mixing formats in one column without normalisation causes painful duplicate-key bugs.
Nil and max UUIDs (all zeros / all ones) appear in RFCs as special values. Do not use them as ordinary record IDs. Reserve them for "unknown" or sentinel cases if your protocol needs one.
RFC 9562 defines several versions. For everyday product work you will meet three most often.
| Version | How it is built | Sorts by time? | Typical use | Watch-outs |
|---|---|---|---|---|
| v1 | Timestamp + clock sequence + node (often MAC) | Yes (Gregorian time layout) | Legacy systems | Can leak MAC / creation time; prefer v7 for new time-ordered IDs |
| v4 | 122 random bits + version/variant | No | Public IDs, opaque keys, browser-side IDs | Random inserts can fragment B-tree indexes |
| v7 | Unix ms timestamp + random bits | Yes | Database primary keys, event IDs | Reveals creation time if the ID is public |
Version 1 was the classic time-based UUID in RFC 4122. It can expose a host MAC address when the node field is a real MAC, which is why many teams moved to v4. RFC 9562 still documents v1 and also v6 (a time-ordered rearrangement of v1). For new designs that want time ordering, the RFC recommends v7 over v1 or v6 when possible.
Version 4 is the workhorse on the web. Browsers expose crypto.randomUUID(), which returns a v4 value from a cryptographically strong RNG. The on-site UUID generator follows the same idea with crypto.getRandomValues.
Version 7 puts a Unix epoch millisecond timestamp in the most significant bits, then fills remaining bits with randomness (and optional sub-millisecond counters for monotonicity). IDs created later compare as larger, which helps clustered indexes and approximate time sorting without a separate created_at column—though you should still store real timestamps when business logic needs them.
Other versions exist (name-based v3/v5 with MD5/SHA-1 namespaces, and custom v8). Use name-based UUIDs when the same input must always map to the same ID. Do not invent a DIY layout and call it a UUID unless you follow v8 rules and document the fields.
Choose based on visibility and storage, not fashion.
A practical split many teams adopt: v7 inside the database, v4 (or a separate public token) at the API boundary. That keeps indexes friendly while URLs stay opaque. If you only mint one ID and it is user-visible, v4 is the safer default.
v7 is not "more unique" than v4. Both rely on large random spaces (plus time uniqueness for v7 within a node's generator). The difference is structure and side channels, not a mystical uniqueness upgrade.
Language support is catching up. Python's uuid module has long offered v1/v3/v4/v5; newer releases and libraries add v7 helpers. In JavaScript, crypto.randomUUID() is v4. For v7 in the browser or Node, use a maintained library that cites RFC 9562 rather than a one-off gist.
// Browser / modern runtimes: version 4
const id = crypto.randomUUID();
console.log(id); // e.g. 3f1a0c2e-9b4d-4e2a-8c1f-7a6b5d4e3c2b
# Python: version 4
import uuid
print(uuid.uuid4())Whatever you pick, document it in your API guide. Clients that assume IDs are sortable will break on v4. Clients that assume IDs hide time will be surprised by v7.
"What if two UUIDs clash?" is the most common worry and almost never the real production bug. For v4, 122 random bits give about 5.3×1036 possible values. Birthday-paradox maths says you need on the order of 261 random v4 UUIDs (around 2.7 quintillion) before a 50% chance of one collision—far beyond normal application scale.
Real collisions and "duplicate key" incidents usually come from other causes:
Math.random to fake a UUIDDefend against those. Keep a unique constraint on the column. Use a CSPRNG. Do not shorten UUIDs. Normalise string formatting at the boundary. Those steps matter more than fretting about astronomical birthday odds.
If you truly need centrally guaranteed uniqueness for regulatory reasons, allocate IDs from a service—but that reintroduces the coordination UUID was designed to avoid. Most product databases are fine with RFC generators plus a unique index as a backstop.
UUIDs identify; they do not authenticate by themselves. A v4 UUID has plenty of entropy against guessing in bulk, but that still does not make it a password, an API key or an OAuth client secret.
If you need a browser-side random ID for idempotency, a v4 UUID is reasonable. If you need a login secret, use the password generator (or your password manager) and store only a slow hash server-side.
Capability URLs ("anyone with the link") sometimes use a UUID as the unguessable path segment. That can work for low-sensitivity shares if you add expiry, revoke endpoints and HTTPS-only delivery. It is still a capability secret: rotate on leak, and never put it in third-party analytics query strings if you can avoid it.
As primary keys, UUIDs avoid exposing sequential integers in URLs and simplify merges across shards. The cost is wider keys and, for v4, more random insert IO on B-trees. v7 reduces that pain. Some teams keep a bigserial internal key and a separate public UUID; that is valid when joins stay on the narrow integer.
In HTTP APIs, return UUIDs as strings. Accept with or without hyphens if you document normalisation. Prefer lowercase in responses. Use UUIDs as idempotency keys on POST payment or signup endpoints so retries do not create duplicate rows.
In logs, a UUID correlation ID per request makes distributed tracing easier. Generate one at the edge and pass it downstream in a header. v7 correlation IDs sort roughly by time in log stores; v4 ones do not—pick based on whether operators want time-sortable IDs.
Indexes: unique constraints belong on every UUID primary key or natural UUID business key. Partial indexes can cover "active" rows. Avoid indexing the textual form twice (with and without hyphens). Pick one storage type.
ORMs sometimes default to v4. Check migrations when you adopt v7 so application code and database defaults agree. A mismatch where the app sends v4 and the DB default is v7 is fine if both are unique; a mismatch where code assumes sortability is not.
For bulk imports, generate UUIDs in the worker before insert so failed retries can reuse the same IDs safely. That pattern pairs well with idempotent upserts.
crypto.randomUUID, uuid.uuid4, or equivalent). Skip home-grown hex from Math.random.Test fixtures should generate fresh UUIDs or use a small reserved set that never ships to production. Famous sample IDs from documentation have a habit of appearing in live rows when someone copies a tutorial.
When debugging "duplicate UUID" reports, check for truncated indexes, case folding in MySQL collations, and ETL jobs that reload the same file. Those explanations show up far more often than true random collisions.
Finally, name fields clearly: public_id versus id, or resource_uuid, so reviewers see which identifiers leave the trust boundary.
A UUID is a 128-bit identifier written as 32 hex digits in five groups. It lets different systems create unique IDs without talking to a central counter.
Yes. GUID is the name Microsoft commonly uses for the same 128-bit identifier family.
v4 is mostly random and does not sort by time. v7 embeds a Unix millisecond timestamp so values roughly increase over time, which helps many database indexes but can reveal creation time.
In theory yes; in practice a correct v4 or v7 generator makes collisions vanishingly unlikely. Most duplicate-key bugs come from bad RNGs, truncated values or copied fixture IDs.
No. UUIDs are identifiers. Use a password manager or password generator for secrets, hash passwords properly, and design API keys with revocation and scopes.
v7 is often best for internal primary keys that need time-local inserts. Use v4 when the same ID is exposed publicly and you want to avoid leaking creation time.
Hex digits are not case sensitive in meaning. RFC 9562 says to output lowercase and accept either case on input.
Use a trusted tool such as the free UUID generator on mfaysal.com, which creates v4 UUIDs in your browser without uploading data.
Last checked: 18 October 2026. Specs and docs can change, so confirm anything important with the official source linked above.
Base64 encoding turns any sequence of bytes into a safe string of ASCII characters using a 64-symbol alphabet, with = used as padding when the input length is not a multiple of three.
A strong password is long, unique to one account, and hard to guess. The practical way to get there is a password manager that creates and stores a different secret for every site, plus a memorable passphrase for the manager itself and for email.
Validate PHP uploads with UPLOAD_ERR_OK, finfo MIME detection, size limits and random names — and ignore $_FILES type and the original filename.
A tested PHP login with sessions and PDO: password_verify, session_regenerate_id on success, a protected dashboard, and a logout that clears the session cookie.