UUID Generator — UUIDv7, v4, v1, v5
Generate cryptographically random v4 UUIDs instantly with this free online UUID generator. Bulk generate up to 100 UUIDs at once, copy individually or all together with one click, and download as a text file. Options include uppercase formatting, hyphen removal, and wrapping in curly braces for GUID-style output. This tool uses your browser's native crypto.randomUUID() API — the gold standard for cryptographically secure random ID generation. All UUIDs are generated entirely in your browser. Nothing is sent to a server. Works offline, no signup required.
A UUID (Universally Unique Identifier, RFC 9562) is a 128-bit identifier represented as a 36-character hyphenated hex string. UUID v4 is fully random. UUID v7 (finalized 2024) embeds a millisecond timestamp at the start, making it monotonically sortable — ideal for database primary keys because the B-tree index stays clustered by insertion order. This free UUID generator produces v1, v4, v6, and v7.
Examples
f47ac10b-58cc-4372-a567-0e02b2c3d479122 bits of entropy. Best for opaque public-facing IDs.
018f9b6c-4123-7890-abcd-ef1234567890First 48 bits are a Unix millisecond timestamp. IDs sort chronologically.
Use v7 for database primary keys and event sourcing. Use v4 when timestamp leakage is a privacy concern.
UUIDs explained — RFC 4122, RFC 9562, and which version to use in 2026
UUIDs are the connective tissue of modern distributed systems. Every Stripe charge, every Auth0 session, every Slack message, every S3 multipart upload — they all carry a 128-bit identifier that was generated independently on whatever node happened to handle the request. That independence is the entire point: no central registry, no ID server, no race condition, no merge conflict. This guide walks through the full UUID specification family — RFC 4122 (the original 2005 standard) and RFC 9562 (its 2024 successor that introduced UUIDv7), the seven defined versions and what each is actually for, the index-fragmentation trap that hits every team eventually, and the language-by-language code you need to generate them safely.
What a UUID actually is — anatomy of 128 bits
A UUID is 128 bits, written as 32 hexadecimal characters split by hyphens into the canonical form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The bytes are not random freeform — two specific positions encode the version and variant:
- Position 13 (the "M" character) — the version digit.
4means random (v4),7means time-ordered (v7),1means timestamp+MAC, etc. - Position 17 (the "N" character) — the variant. The high bits are
10(binary), so the hex is one of8,9,a,b. This identifies the UUID as RFC 4122/9562 (the "Leach-Salz" variant) versus older Microsoft/NCS variants.
Because the version and variant nibbles eat 6 bits, a v4 UUID has 122 random bits, not 128. The collision math you might have seen — "you'd need to generate 2.71 quintillion UUIDs to have a 50% chance of one collision" — is based on those 122 bits applied to the standard birthday-paradox formula n ≈ 1.177 × √(2^122).
The seven UUID versions, when to use each
If you are starting a new project in 2026, default to v7. If you are stuck on a runtime that does not yet implement v7 (older language stdlibs), v4 is still safe — just be aware of the index-fragmentation cost at scale.
The index-fragmentation problem — why v4 hurts at scale
Databases store primary-key indexes as B-trees (or B+ trees). When IDs arrive in roughly sorted order — autoincrement integers, ULIDs, UUIDv7 — every new row inserts at the tail of the index, the page stays full, and the cache hit rate is high. When IDs are random — UUIDv4 — every insert lands in a different B-tree page. Pages split, rewrites cascade, and the tail of the working set blows out of memory. Real-world impact:
- Postgres: v4 vs sequential ID inserts can be 2–3× slower at scale because of WAL volume and buffer cache thrashing.
- MySQL/InnoDB: primary key drives the clustered index. Random inserts cause page splits and bloat the on-disk size by 30–60%.
- SQL Server: same pattern;
NEWSEQUENTIALID()exists exactly because random GUIDs hurt.
The fixes, in order of preference: (1) UUIDv7, which preserves uniqueness while putting the high-order bits in time order; (2) ULID — same idea, different encoding; (3) store v4 UUIDs as native BINARY(16)/uuid columns rather than VARCHAR(36), halving size; (4) on MySQL, use UUID_TO_BIN(uuid, 1) which reorders v1 bytes for B-tree locality.
Generating UUIDs safely in 8 languages
Always use a cryptographically secure RNG. Math.random(), java.util.Random, and rand() in C are not safe — they have predictable internal state and can collide.
// v4 — built in
const id = crypto.randomUUID();
// v7 — implement with crypto.getRandomValues
function uuidv7() {
const ts = BigInt(Date.now());
const rand = crypto.getRandomValues(new Uint8Array(10));
const b = new Uint8Array(16);
// 48-bit timestamp
for (let i = 0; i < 6; i++) b[i] = Number((ts >> BigInt(40 - i*8)) & 0xffn);
b.set(rand, 6);
b[6] = (b[6] & 0x0f) | 0x70; // version 7
b[8] = (b[8] & 0x3f) | 0x80; // variant 10
const h = [...b].map(x => x.toString(16).padStart(2,'0')).join('');
return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}import uuid
uuid.uuid4() # v4
uuid.uuid7() # v7 (Python 3.13+; on older, use the `uuid7` PyPI package)
uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com/users/42") # v5import "github.com/google/uuid"
id4 := uuid.New() // v4
id7, _ := uuid.NewV7() // v7 (v1.6.0+)import java.util.UUID;
UUID id = UUID.randomUUID(); // v4
// v7 — needs a library, e.g. com.github.f4b6a3:uuid-creator
import com.github.f4b6a3.uuid.UuidCreator;
UUID v7 = UuidCreator.getTimeOrderedEpoch();use uuid::Uuid;
let id = Uuid::new_v4();
let v7 = Uuid::now_v7(); // requires the `v7` featureuse Symfony\Component\Uid\Uuid;
$v4 = Uuid::v4();
$v7 = Uuid::v7();require 'securerandom'
SecureRandom.uuid # v4
# v7 — needs a gem like `uuidx`
require 'uuidx'
Uuidx.v7SELECT gen_random_uuid(); -- v4 (built-in since 13)
-- v7 — install pg_uuidv7 extension or upgrade to PG 18 which adds uuidv7()Common UUID mistakes I see in code review
- Treating UUIDs as secrets. A UUID is an identifier, not a token. Anyone who sees it can use it to address the resource. Pair UUIDs with proper authentication.
- Storing UUIDs as
VARCHAR(36). 36 bytes for the string vs 16 bytes for native binary. Postgres hasuuid, MySQL 8 hasBINARY(16)withUUID_TO_BIN(), SQL Server hasuniqueidentifier. Use them. - Using v1 in 2026. The MAC-address bytes leak which physical machine generated the ID. v7 gives you the same time-ordering benefit without the leak.
- Validating UUIDs with the wrong regex.
/^[0-9a-f-]{36}$/accepts garbage likeaaaa-aaaa-.... The correct shape requires the specific positions and the variant nibble:/^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. - Generating v4 UUIDs with
Math.random(). The classic"xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx".replace(...)snippet from Stack Overflow usesMath.random(), which is not cryptographically secure. Usecrypto.randomUUID()in any browser since 2021. - Embedding UUIDs in user-facing URLs. Long, ugly, non-memorable. Keep UUIDs as the internal ID and expose a slug or short-hash for shareable links.
- Sorting v4 UUIDs and expecting time order. v4 is uniformly random; the result is meaningless ordering. Use v7 if you need this.
UUID vs ULID vs NanoID vs CUID2 — picking an ID format
| Format | Bits of randomness | Sortable? | Length | Standard? |
|---|---|---|---|---|
| UUIDv4 | 122 | No | 36 chars (32 hex + 4 hyphens) | RFC 4122 / 9562 |
| UUIDv7 | 74 + 48-bit time | Yes | 36 chars | RFC 9562 |
| ULID | 80 + 48-bit time | Yes | 26 chars (Crockford base32) | De-facto, no RFC |
| NanoID (default) | 126 (21 chars × 6 bits) | No | 21 chars | De-facto |
| CUID2 | ~256 (sha-3 derived) | No | 24 chars (configurable) | De-facto |
Practical guide: use UUIDv7 if your stack and database support it. Use ULID if you want a shorter, more URL-friendly time-ordered ID. Use NanoID for short opaque IDs (8–12 chars) where 128 bits is overkill. Use UUIDv4 if interop with old systems matters more than performance.
Best UUID generator online for 2026 — UUIDv7 vs v4 comparison
"UUIDv7" search volume has overtaken "UUID v4" generators in 2026 because RFC 9562 (May 2024) made it a first-class standard, and major databases (PostgreSQL 18, MySQL 8.4, SQL Server 2025) ship native v7 support. The right generator is no longer just "v4 random" — you need v4 for randomness-critical IDs and v7 for everything stored in a B-tree index. Here is how the most-used UUID generators compare in 2026:
| Tool | UUIDv7 | v4 / v1 / v5 | Bulk (100+) | Browser-only | Cost |
|---|---|---|---|---|---|
| FreeDevTool UUID Generator | Yes | v4 + v1 + v5 | Up to 1,000 | Yes | Free |
| uuidgenerator.net | Yes (added 2024) | v4 + v1 | Up to 100 | Yes | Free, ad-funded |
| uuid.rocks | Yes | v4 + v7 + ULID + nanoid | Up to 100 | Yes | Free |
| online-toolz UUID | No (v4 only) | v4 only | Up to 50 | Yes | Free, ad-funded |
uuid npm library | v7 added in v10 | All versions | Programmatic | Local install | Free, OSS |
PostgreSQL gen_random_uuid() | v7 native in PG 18 | v4 standard | Programmatic | Server-side | Free |
What is UUIDv7 and when should I use it instead of v4?
UUIDv7 is a time-ordered UUID — the first 48 bits are a Unix-millisecond timestamp, then 74 random bits, plus version/variant fields. It is identical in shape to v4 (same 36-char hex format) but sorts chronologically. Switch from v4 → v7 whenever the UUID is stored in a B-tree index (Postgres, MySQL, SQL Server, MongoDB _id). Random v4 IDs scatter writes across the index and cause page splits — measurements on InnoDB show v4 inserts ~3× slower than v7 at 10M+ rows. Keep v4 only when the ID must NOT leak time information (security tokens, share-by-URL secrets where a guess of the timestamp helps an attacker). For everything else in 2026, default to v7.
How do I generate a UUIDv4 that is truly random and safe for security tokens?
Three rules. One: use a CSPRNG, not Math.random(). The browser's crypto.randomUUID() calls a NIST-validated CSPRNG; this generator uses it directly. Two: never seed v4 from a timestamp or username — that defeats the 122 random bits. Three: never use a v4 UUID as a session token or password reset link. v4 is unique, but it is not a secret-strength random — only 122 bits of entropy after the version bits, no padding, and brute-forceable for short-lived secrets. Use a 256-bit CSPRNG token (Node's crypto.randomBytes(32).toString('hex'), the Hash Generator's SHA-256 of a random nonce, or a JWT signed with a secret key) for anything that grants access. UUIDs are identifiers, not credentials.
UUIDv7 vs ULID vs NanoID vs CUID2 — picking an ID format in 2026
Decision tree: B-tree DB primary key in 2026 → UUIDv7. Pre-RFC-9562 codebase that already uses ULID → keep ULID (interop is fine, just don't mix). Public URL slug where you want short → NanoID. Internal high-throughput service with Snowflake already in place → keep Snowflake. Random secret/token → not a UUID at all, use a 256-bit CSPRNG nonce.
UUID generator alternative to uuidgenerator.net — 4 reasons developers switched
- UUIDv7 is the default, not buried in a tab. Most online generators surface v4 because that's what they were originally built for. UUIDv7 is the right default in 2026 for any database key.
- Bulk up to 1,000. Database seed scripts and load tests need batches well past 100. Most generators cap at 50–100.
- Side-by-side v1 / v4 / v5 / v7. Compare the byte layout when migrating — v7's leading timestamp bytes are visible in the generator output, which makes the index-fragmentation argument concrete instead of abstract.
- No ads, no tracker pixels. Tools indexed for "online uuid", "uuidv4 generator", "generate uuid" almost universally inject ad slots that delay paint — measurable hit on Largest Contentful Paint. This page is browser-only and ad-free.
Pair the UUID generator with the Complete UUID Guide for the deeper RFC 9562 / RFC 4122 walk-through, the Hash Generator for SHA-1 in v5 namespace UUIDs, and the Unix Timestamp Converter for decoding the leading timestamp bytes of any v7 UUID.
How to use the UUID generator
UUIDs (or GUIDs) are 128-bit identifiers used as primary keys, request IDs, idempotency tokens, and feature-flag identifiers. The generator produces RFC 4122 v4 UUIDs (random) by default — cryptographically random via crypto.getRandomValues(), generated entirely in your browser. No collisions in practice; no network calls.
- 1. Click "Generate" for a single UUID, or set a count (1–1000) to produce a batch for test fixtures or seed data.
- 2. Pick the format: hyphenated (
550e8400-e29b-41d4-a716-446655440000), no hyphens, uppercase, or wrapped in braces for older Microsoft systems. - 3. Copy a single UUID with one click, or "Copy all" for the full batch — separated by newlines or commas.
- 4. Download as a text or JSON file for larger batches headed into a database seeder or test suite.
- 5. Toggle UUIDv7 if you need a time-ordered ID (better B-tree index locality than v4) — newer apps should default to v7.
Common UUID mistakes to avoid
- Using UUIDv4 for sortable primary keys. v4 is fully random — terrible for B-tree index locality, causes write hotspots in MySQL/Postgres. For new tables, use
UUIDv7(time-ordered) or a ULID. - Storing UUIDs as
VARCHAR(36)when your DB has a native type. Postgres hasuuid, MySQL 8 hasUUID_TO_BIN()for binary 16-byte storage. Native types are 2.25× smaller and faster. - Using UUIDv1 (timestamp + MAC). Leaks the server's MAC address and clock — privacy and security concern. Stick to v4, v7, or ULID.
- Treating UUIDs as secret tokens. A UUID is an identifier, not authentication. Don't use them as session tokens or API keys — use proper random secrets with proper entropy.
- Generating UUIDs with
Math.random(). Not cryptographically secure — collisions are theoretically possible across enough generations. Usecrypto.randomUUID()(built-in to modern browsers and Node 14+). - Embedding UUIDs in user-facing URLs. Long, ugly, and unindexable by humans. Use a short slug or hash for shareable URLs; keep UUIDs as the internal ID.
Frequently Asked Questions
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. It is designed to be unique across distributed systems without a central coordinator. UUID is standardized in RFC 4122 and used in databases, APIs, file systems, and distributed architectures worldwide.
v4 — 122 bits of pure randomness. The most commonly used version. No structure, no reversibility.
v5 — deterministic: given the same name and namespace, you always get the same UUID (uses SHA-1). Good for content-addressed identifiers.
v7 — new standard: timestamp-ordered v4. Solves index fragmentation in databases while keeping randomness.
crypto.randomUUID() — a cryptographically secure random number generator — not Math.random().
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx format.
crypto.randomUUID()JavaScript (Node.js 14.17+):
require('crypto').randomUUID()Python:
import uuid; str(uuid.uuid4())Go:
import "github.com/google/uuid"; uuid.New().String()PostgreSQL:
SELECT gen_random_uuid();MySQL:
SELECT UUID();
Browse all 50 free developer tools
All tools run in your browser, no signup required, nothing sent to a server.