How to Generate a UUID (v4, v1, v7) — Full Guide

Independently researched No sponsored picks Affiliate supported

A UUID (Universally Unique Identifier) is a 128-bit value, written as 36 characters like f47ac10b-58cc-4372-a567-0e02b2c3d479, used to label something so uniquely that you never have to coordinate with a central server to avoid clashes. The fastest way to make one is to open a free UUID Generator in your browser, click generate, and copy it — or in code, call crypto.randomUUID() (JavaScript) or uuid.uuid4() (Python). This guide explains the versions, the (tiny) collision odds, when to choose UUIDs over auto-increment IDs, and exactly how to generate them everywhere.

What Is a UUID?

A UUID — also called a GUID (Globally Unique Identifier) in Microsoft ecosystems — is a 128-bit number. It is almost always shown as 32 hexadecimal digits split into five groups by hyphens, in the pattern 8-4-4-4-12:

f47ac10b-58cc-4372-a567-0e02b2c3d479
└──────┘ └──┘ └──┘ └──┘ └──────────┘
   8       4    4    4        12

The whole point of a UUID is decentralized uniqueness. Two different machines, with no network connection between them and no shared counter, can each generate UUIDs and trust that they will not collide. That property makes UUIDs perfect for distributed systems, offline-first apps, merging databases, and any situation where you need an ID before you talk to a server.

The format is defined by RFC 9562 (which in 2024 superseded the older RFC 4122). Inside the 128 bits, a few bits are reserved to encode the version (which algorithm created the UUID) and the variant (which layout standard it follows). Everything else is payload — random bits, timestamp bits, or node bits depending on the version.

UUID Versions Compared

There are several UUID versions, but in modern application code you really only care about three: v4, v1, and v7. Here is how they stack up.

Version How it’s built Sortable by time? Privacy Best for
v1 Timestamp + clock sequence + node (often MAC address) Roughly, but messy Leaks MAC + creation time Legacy systems needing time + node info
v3 MD5 hash of a namespace + name No Deterministic Reproducible IDs from known input
v4 122 random bits No Reveals nothing General-purpose IDs (the default choice)
v5 SHA-1 hash of a namespace + name No Deterministic Like v3 but stronger hash
v7 Unix-ms timestamp + random bits Yes (lexicographically) Reveals only creation time Database primary keys, event logs

Version 4 (random) — the default

A v4 UUID is mostly randomness: 122 of its 128 bits are random, with the remaining 6 bits fixed to mark it as version 4 and the correct variant. It carries no timestamp, no machine info, and no order. Because it leaks nothing and needs no special hardware or clock, v4 is the right default for the vast majority of use cases.

Version 1 (time-based) — handle with care

A v1 UUID encodes the current timestamp, a clock sequence, and a “node” — traditionally the machine’s MAC address. That means a v1 UUID can reveal which machine created it and roughly when. That is occasionally useful, but it is also an information leak, so avoid v1 for anything user-facing or security-sensitive.

Version 7 (time-ordered) — the modern sweet spot

Version 7 is the newest and, for many database workloads, the best. The leading bits are a millisecond Unix timestamp and the rest are random. Because the timestamp comes first, v7 UUIDs sort chronologically when compared as strings or bytes. You get the unguessability of v4 plus the database-friendly ordering of an auto-increment key — without leaking a MAC address. If your platform supports v7, it is an excellent choice for primary keys.

How to Generate a UUID

Method 1: Use a free online UUID generator (no install)

The quickest path needs zero setup:

  1. Open the UUID Generator.
  2. Pick the version you want (v4 is the default).
  3. Optionally set how many you want — single, or a batch of dozens.
  4. Click generate and copy the result.

Everything runs in your browser using the same crypto API your code would use, so nothing is uploaded to a server. It is the fastest way to grab a one-off ID for a test fixture, a config file, a seed script, or a database row.

Method 2: JavaScript / TypeScript

Modern browsers and Node.js (18+) include a built-in generator. No library required:

// Built-in, returns a v4 UUID — works in browsers and Node 18+
const id = crypto.randomUUID();
console.log(id);
// → "3f29c1de-8b2a-4f6e-9c1d-7a2b3c4d5e6f"

If you need v1 or v7, or you support older runtimes, the uuid package covers every version:

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

uuidv4(); // "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"  random
uuidv1(); // "aa8c43a0-..." time + node based
uuidv7(); // "018f3a2b-..." time-ordered

Method 3: Python

The standard library has had uuid built in for years — nothing to install:

import uuid

print(uuid.uuid4())   # random  → "f47ac10b-58cc-4372-a567-0e02b2c3d479"
print(uuid.uuid1())   # time + node based

Python 3.x’s standard library does not yet ship uuid7, so for time-ordered UUIDs use a small package like uuid6 or uuid-utils:

# pip install uuid6
from uuid6 import uuid7
print(uuid7())        # "018f3a2b-7c1e-7abc-8def-0123456789ab"

Method 4: SQL databases

Most databases can generate UUIDs server-side as a column default:

-- PostgreSQL 13+ (built-in v4)
SELECT gen_random_uuid();

-- PostgreSQL table default
CREATE TABLE users (
  id   uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name text NOT NULL
);

-- MySQL 8.x (v1-style)
SELECT UUID();

-- SQL Server
SELECT NEWID();

PostgreSQL 18 also adds native uuidv7() for time-ordered keys. On MySQL, store UUIDs in a BINARY(16) column (via UUID_TO_BIN()) rather than CHAR(36) to save space and speed up indexes.

Method 5: Command line

For a one-liner in a terminal or shell script:

# Linux / macOS — reads the kernel's UUID source
cat /proc/sys/kernel/random/uuid     # Linux
uuidgen                              # macOS / most Unix

# Python one-liner (works anywhere Python is installed)
python3 -c "import uuid; print(uuid.uuid4())"

How Likely Is a UUID Collision?

Practically zero. A version 4 UUID has 122 random bits, which yields about 5.3 x 10^36 possible values (roughly 5.3 undecillion).

To build intuition, here is the rough chance of any collision after generating n random v4 UUIDs, using the birthday-paradox approximation:

UUIDs generated Approx. collision probability
1 million ~0.0000000000000001% (negligible)
1 billion ~0.00000000001%
103 trillion ~50%

You would have to generate about a billion UUIDs every second for roughly 85 years to reach a 50% chance of a single collision. For any normal application, treating v4 UUIDs as unique is completely safe — you are far more likely to lose data to a bug, a bad migration, or a disk failure than to a genuine UUID clash.

One caveat: this only holds when the randomness is good. If you generate UUIDs from a weak or unseeded random number generator, collisions become possible. The browser crypto.randomUUID() and the language standard libraries above all use cryptographically secure randomness, so stick with them rather than rolling your own from Math.random().

UUIDs vs. Auto-Increment IDs

A common question is whether to use UUIDs or classic sequential integer keys (1, 2, 3, ...). Neither is universally “better” — they trade off different things.

Factor Auto-increment integer UUID
Size 4–8 bytes 16 bytes (128 bits)
Generated by Database (needs a round trip) Anyone, anywhere, offline
Guessable / enumerable Yes (exposes record counts) No (v4/v7)
Merge two databases Painful — keys collide Trivial — keys are unique
Index locality Excellent (always appended) Poor for v4, good for v7
Human-friendly Very (order #1043) No

Choose auto-increment when you have a single database, you want the smallest possible keys and fastest joins, and human-readable IDs are nice to have. The downside is that sequential IDs leak business data — a competitor can read ?invoice=58213 and learn roughly how many invoices you’ve issued, then enumerate other records.

Choose UUIDs when you generate IDs on the client or across multiple services, you need to merge or shard data, or you don’t want IDs to be guessable. The classic objection — that random v4 keys hurt B-tree index performance because new rows scatter across the index — is exactly what v7 solves: its time-ordered prefix keeps inserts clustered at the “end” of the index like an auto-increment key, while staying globally unique. For new systems that want UUID benefits without the index penalty, v7 is the answer.

Common Mistakes and Pitfalls

  • Using v1 for public IDs. A v1 UUID can expose your server’s MAC address and the exact creation time. Use v4 or v7 for anything users can see.
  • Generating UUIDs with Math.random(). It is not cryptographically secure and can produce predictable or repeating values. Always use crypto.randomUUID() or a real UUID library.
  • Storing UUIDs as text when you don’t have to. CHAR(36) wastes space and slows indexes. Prefer a native uuid/BINARY(16) column.
  • Assuming UUIDs are sortable. v4 UUIDs have no order — sorting by them is effectively random. If you need chronological ordering, use v7 or add a separate timestamp column.
  • Treating a UUID as a secret. A UUID is unique, not secret. Knowing one doesn’t let an attacker guess others, but you should not use a UUID as an authentication token or password substitute.
  • Mixing versions in one column without noticing. It works, but you lose any ordering guarantee. Pick one version per identifier role and stick with it.

Quick Decision Guide

  • Need a one-off ID right now? Grab one from the UUID Generator.
  • Building general app IDs? Use v4 (crypto.randomUUID() / uuid.uuid4()).
  • Designing database primary keys? Use v7 for time-ordered, index-friendly keys.
  • Need the same ID from the same input every time? Use v5 (namespace + name).
  • Maintaining a legacy system that expects time + node IDs? Use v1, but be aware of the privacy trade-off.

Frequently Asked Questions

What is the fastest way to generate a UUID?

Open a free in-browser UUID Generator, click generate, and copy the result — no install needed. In code, use crypto.randomUUID() in JavaScript or uuid.uuid4() in Python, both of which return a standard version 4 UUID instantly.

Which UUID version should I use?

Use v4 (random) for most general-purpose identifiers. Use v7 when you want randomness plus time-ordering for better database index locality. Use v1 only when you specifically need timestamp-and-node-based IDs, since it can leak the MAC address and creation time.

Can two UUIDs ever be the same?

In theory yes, in practice almost never. A version 4 UUID has 122 random bits, giving about 5.3 x 10^36 possible values. You would need to generate billions of UUIDs per second for many years before a collision becomes even remotely likely.

Once you’ve generated your IDs, you might also need to inspect or transform other data formats. These free, in-browser tools and guides pair well with UUID work:

Ready to make one? Open the free UUID Generator — it runs entirely in your browser, generates v4 UUIDs in bulk, and never uploads anything. Paste nothing, click generate, copy your ID.

Why Trust FindPicked?

Our recommendations are based on extensive research, real user reviews, and spec-by-spec analysis. We never accept payment for placement. When you buy through our links, we may earn a commission — this supports our work at no extra cost to you.

Learn how we pick →