Is a GUID the same as a UUID?

Yes. GUID and UUID refer to the same 128-bit identifier. GUID is Microsoft's name and often uses uppercase hex inside braces. Our GUID tab outputs that format.

Should I use UUID or auto-increment for primary keys?

Use auto-increment when a single database owns all rows and you want minimal storage. Use UUID (usually v4 or v7) when merging databases, exposing public IDs, or generating keys offline without a central server.

What is the difference between UUID v4 and v7?

Version 4 is entirely random — great for opaque IDs. Version 7 embeds a millisecond timestamp in the leading bits so new IDs sort roughly by creation time, which helps B-tree index performance in large tables.

Can two UUIDs ever collide?

Theoretically yes, but the probability for Version 4 is negligible at any practical scale. Still add a UNIQUE constraint in your database — application bugs or bad random sources are more likely than a random collision.

When should I use the nil UUID?

Use the nil UUID (00000000-0000-0000-0000-000000000000) only as a defined sentinel meaning “no UUID assigned,” not as a generated primary key. Prefer SQL NULL for missing values in most schemas.

Where is the free UUID generator on ShoutingNow?

Open the UUID Generator tool — five version tabs, bulk up to 500, copy, and download. All generation runs in your browser with no signup.

UUID Generator Guide: Versions, Use Cases & Database Tips (2026)

A UUID (Universally Unique Identifier) is a 128-bit label formatted as 36 characters — 32 hex digits plus four hyphens. Teams reach for UUIDs when auto-increment integers are too predictable, when databases must merge without ID clashes, or when an API needs opaque resource identifiers. This guide explains what UUIDs are, how each major version works, and when to pick one. When you need a value right now, open our free UUID Generator — Version 1, 4, 7, nil, and GUID formats, bulk up to 500, copy or download, all in your browser.

Generate a UUID now: Open the UUID Generator — RFC 4122 v1/v4, RFC 9562 v7, nil UUID, and braced GUID. No signup, no server round-trip.

What is a UUID?

Think of a UUID as a very large random (or time-stamped) number written in hexadecimal. The standard layout is:

550e8400-e29b-41d4-a716-446655440000
|  time/random  | ver | var |      node / random       |

That string holds 128 bits — enough combinations that accidental collision is negligible for practical systems, provided you use a proper generator and enforce uniqueness in your schema.

UUIDs appear under several names: GUID (Globally Unique Identifier) in Microsoft ecosystems, uuid in PostgreSQL, and uniqueidentifier in SQL Server. The bit pattern is the same; only formatting conventions differ.

How UUID generation works (by version)

Version 4 — random (recommended default)

Version 4 sets 122 random bits and fixes 6 bits for version (4) and variant (10 binary prefix). Browsers expose this via crypto.randomUUID() or crypto.getRandomValues(). Use v4 for primary keys, session IDs, and public API resources when you do not need sort order.

Version 7 — time-ordered (modern alternative to v1)

Version 7 (RFC 9562) places a 48-bit Unix timestamp in milliseconds in the leading bits, then fills the rest with random data. Indexes on v7 columns stay roughly sequential like auto-increment, but IDs remain opaque and do not embed MAC addresses.

Version 1 — timestamp + node

Version 1 encodes a 60-bit timestamp (100-ns intervals since 15 October 1582) plus a clock sequence and 48-bit node field. Historically the node was a MAC address; modern generators randomize it. Prefer v7 unless a legacy dependency requires v1.

Nil UUID

The nil UUID is the constant 00000000-0000-0000-0000-000000000000. Schemas use it to mean “no identifier set.” Do not insert it as a real primary key.

GUID format

A GUID wraps the same value in curly braces with uppercase hex: {550E8400-E29B-41D4-A716-446655440000}. Our GUID tab produces this format from a Version 4 UUID.

UUID format and formulas

Standard string form:

UUID = time_low "-" time_mid "-" time_hi_and_version "-"
       clock_seq_and_variant "-" node

For Version 4, random bytes R[0..15] are adjusted:

R[6]  = (R[6]  & 0x0F) | 0x40   // version 4
R[8]  = (R[8]  & 0x3F) | 0x80   // RFC variant

Collision risk for v4 is dominated by the birthday paradox: with n generated IDs, approximate collision probability scales with n² / 2^122 — astronomically small at any realistic n.

Step-by-step: generate and use a UUID

Open the UUID Generator and choose a version tab (Version 4 for most cases).
Click Generate and copy the result, or enter a bulk count (max 500) and export via Copy all or Download.
Store the value in your database column typed as UUID, CHAR(36), or native binary (16 bytes) depending on your engine.
Add a UNIQUE constraint — never rely on probability alone.
For public URLs, prefer v4 or v7 over sequential integers to avoid enumeration.

Example in databases

CREATE TABLE orders (
  id         UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id    UUID NOT NULL,
  total_cents INTEGER NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

PostgreSQL's gen_random_uuid() produces Version 4 values server-side. Client-generated UUIDs from our tool are equally valid when inserted explicitly.

Use cases

Scenario	Why UUIDs fit	Suggested version
Microservice order IDs	Each service mints IDs without a shared counter	v4 or v7
Public download links	Non-guessable tokens in URLs	v4
Time-series tables with B-tree indexes	Inserts stay sequential in the index	v7
Offline-first mobile apps	Create records before sync	v4
Log trace IDs	Correlate spans across hosts	v4
.NET / Windows registry	Tools expect braced GUID strings	GUID tab
Nullable foreign key placeholder	Sentinel “empty” value in APIs	Nil UUID (constant)

Common mistakes and solutions

Mistake	Problem	Solution
Using v1 for privacy-sensitive public IDs	Old v1 implementations exposed MAC-derived node bits	Use v4 or v7; ensure node field is randomized
Storing UUID as string without index plan	36-char strings bloat indexes vs 16-byte binary	Use native `UUID` type or `BINARY(16)` where supported
Assuming uniqueness without a DB constraint	Birthday paradox + bugs can collide	Always declare PRIMARY KEY or UNIQUE on the column
Using nil UUID as a real key	Every “empty” row shares one ID	Use NULL for absent keys; reserve nil for explicit sentinel semantics
Mixing uppercase GUID and lowercase uuid in joins	String comparisons fail across formats	Normalize to one casing in application code
Choosing v4 when index locality matters	Random inserts fragment B-tree pages	Switch to v7 for time-ordered clustering
Regenerating v3/v5 name-based IDs incorrectly	Same name must always yield same UUID	Implement RFC name hashing in code — not random generation

UUID vs auto-increment integers

Factor	UUID	Auto-increment
Uniqueness across shards	Strong — no coordinator	Requires central sequence or offset ranges
URL guessability	Low (v4/v7)	High — sequential exposure
Storage size	16 bytes (binary) or 36 chars	4–8 bytes typical
Index locality	v4 random; v7 good	Excellent
Human readability	Poor	Better for small counts

Privacy and security notes

UUIDs from our generator are created locally with your browser's CSPRNG. ShoutingNow does not log or store them. Version 4 and v7 values reveal no user data by themselves, but predictable v1 timestamps can hint at creation order. Treat UUIDs in URLs as capability tokens — anyone with the string may access the resource if authorization is missing.

Generate your next UUID

Use the ShoutingNow UUID Generator for instant Version 1, 4, 7, nil, and GUID output — bulk export included. Bookmark this UUID guide for version comparisons, schema examples, and troubleshooting, then share the tool with your team for unlimited free use.