Free UUID generator — v1, v3, v4, v5, and v7. Bulk-generate up to 100 at once, with QR codes and JSON/TXT/CSV export.

Six independent capabilities. The defaults (v4, 1 UUID, lowercase with dashes) match what most libraries return — but the version selector and bulk count are where this tool earns its keep.

A UUID (Universally Unique Identifier) is a 128-bit value presented as 32 hexadecimal characters arranged in 8-4-4-4-12 groups — e.g. `f47ac10b-58cc-4372-a567-0e02b2c3d479`. The Microsoft Windows ecosystem calls them GUIDs (Globally Unique Identifiers); same thing, different name. Five reasons UUIDs continue to dominate as the default identifier choice:

• No central coordination needed Any machine, anywhere, can generate a UUID without contacting a central coordinator. Two services generating UUIDs simultaneously in different data centers will not collide. This is the property that makes UUIDs the natural choice for distributed systems where coordinated ID assignment would be expensive, slow, or impossible.
• Resistant to enumeration attacks An auto-incrementing integer ID exposes business data. `/users/1234` tells an attacker you have at least 1234 users; `/users/1235` works to crawl your customer base. UUIDs aren't sequential — `/users/f47ac10b-58cc-4372-a567-0e02b2c3d479` reveals nothing about scale, ordering, or other records. URL-based access patterns require explicit authorization, not security-through-obscurity.
• Cross-system stable Identifiers stay stable when data moves between systems. Auto-increment integers from different databases will collide if you merge them. UUIDs can be combined freely — across services, across companies, across acquisitions — without renumbering.
• Predictable database performance — with the right version v7 UUIDs (timestamp-prefixed) cluster newly inserted rows physically near each other in B-tree indexes, keeping page-fill high and inserts fast. v4 UUIDs scatter inserts across the whole index, causing fragmentation. Picking the right version is the difference between UUID-based primary keys being fine and being a database performance disaster.
• The collision math actually works v4 UUIDs have 122 bits of randomness. The 'birthday problem' math says you'd need to generate ~2.7 × 10^18 UUIDs to have a 50% chance of one collision. To put that in context: if every human on Earth generated one UUID per second for 10,000 years, the collision probability would still be negligible. UUIDs aren't 'usually unique' — they're cryptographically unique for any realistic scale.

Every UUID is 128 bits total — 32 hex characters, formatted as 8-4-4-4-12 with dashes (36 chars including dashes). Two specific positions inside that string are reserved for metadata; everything else is version-specific data.

• The structure: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx 32 hex characters (128 bits total). The `M` position (nibble 12) is the version number — 1, 3, 4, 5, 6, 7, or 8. The `N` position (nibble 16) is the variant — for RFC 4122/9562 UUIDs, this is always `8`, `9`, `a`, or `b`. The remaining 122 bits are payload that depends on the version.
• Version bits — 4 bits Tells you how the UUID was generated. You can read any UUID and know its version by looking at the 13th character (after removing dashes, it's the 13th hex digit). `f47ac10b-58cc-4372-a567-0e02b2c3d479` → the `4` after `58cc-` tells you this is a v4 UUID.
• Variant bits — 2 bits Tells you which UUID standard the value follows. RFC 4122/9562 UUIDs use variant `10x` (binary), which renders as `8`, `9`, `a`, or `b` in hex at the 17th character. Other variants exist (Microsoft's older GUID format, Apollo NCS) but they're effectively never seen today.
• Payload — 122 bits Whatever's left after the version and variant. For v4 this is pure random data. For v7 it's a 48-bit Unix-millisecond timestamp followed by 74 random bits. For v3/v5 it's a hash of namespace + name. For v1 it's timestamp + MAC + clock sequence. The version bits tell you how to interpret the payload.

Eight UUID versions exist on paper (v1–v8); five are practical (v1, v3, v4, v5, v7); two are best practice (v4 for legacy compatibility, v7 for new development). The rest are either deprecated (v2), niche (v6, v8), or strictly inferior to alternatives.

• v1 — Time-based + MAC address (1996) Encodes a 60-bit timestamp (100-nanosecond intervals since 1582-10-15), the 48-bit MAC address of the generating machine, and a 14-bit clock sequence. Monotonically increasing when generated rapidly. Two serious problems: leaks the MAC address (privacy issue — UUIDs can be traced back to specific hardware), and the structure makes UUIDs partially predictable. Mostly seen in legacy systems. For monotonic UUIDs in new applications, use v7 instead — it has the same ordering property without the privacy cost.
• v3 — Namespace + MD5 hash Deterministic: given a namespace UUID and a name string, always produces the same UUID. Useful when you need stable IDs for logical entities across systems — 'the UUID for `example.com` is always THIS UUID'. Five standard namespaces are defined in the RFC: DNS, URL, OID, X.500 DN, and NIL. Uses MD5 internally; the cryptographic weaknesses of MD5 don't matter here because namespace UUIDs aren't a security primitive. v5 is preferred for new use cases.
• v4 — Random (the historical default) 122 bits of cryptographically random data (128 minus 4 version bits and 2 variant bits). What virtually every library returns from `uuid.v4()` or equivalent. The most common UUID in production today. Collision probability is negligible for any realistic dataset. Good for: anywhere you don't need ordering or determinism. Slightly suboptimal for: database primary keys at high insert volume (use v7 instead for that case).
• v5 — Namespace + SHA-1 hash Same construction as v3 but uses SHA-1 instead of MD5. Recommended over v3 for new deterministic-UUID use cases — SHA-1 is more secure than MD5 even though both are theoretically broken (and neither's weaknesses matter here). Use case: stable, reproducible UUIDs for logical entities, idempotency keys derived from request content, content-addressed IDs.
• v7 — Unix timestamp + random (RFC 9562, May 2024) — recommended for new applications First 48 bits encode the Unix timestamp in milliseconds; remaining 74 bits are random. Sortable chronologically without leaking machine identity. The single most important property: UUIDs created later sort after UUIDs created earlier, which makes them dramatically better than v4 as database primary keys (B-tree indexes stay clustered, page-fill stays high, recently-inserted rows are physically near each other on disk). The modern best practice for any new system. If your language/framework supports it, prefer v7 over v4 by default.
• v2, v6, v8 — niche v2 (DCE Security UUIDs) encodes POSIX UID/GID; almost never implemented or used. v6 is v1's timestamp re-ordered to be sortable; superseded in practice by v7. v8 is reserved by RFC 9562 for vendor-specific custom layouts — useful only when v1–v7 genuinely don't fit your needs. None of these are commonly exposed in UUID generation tools.

If you remember nothing else: v7 for new systems, v4 for compatibility, v5 for determinism. Everything below is the long version of that.

• Default choice — v7 If your language and database both support v7 (most modern stacks do as of 2025: Postgres 18+ has native `uuidv7()`, MySQL has it via plugins, Node.js has `uuid@10+`, Python has `uuid7` packages), use v7. You get all the benefits of v4 plus chronological sortability plus dramatically better database insert performance. There's no downside vs. v4 for new development.
• Compatibility fallback — v4 If your stack doesn't yet support v7, or you're working with systems that only validate the v4 format, use v4. It's been the default for ~20 years; everything supports it. Just be aware that v4 primary keys at high insert volume can degrade database performance over time — if you ever migrate to v7, you'll see meaningful improvements.
• Deterministic IDs — v5 When you need the same input to always produce the same UUID — content-addressed IDs, idempotency keys derived from request bodies, stable identifiers for logical entities. Pick v5 (SHA-1) over v3 (MD5); both work, v5 is slightly preferred.
• Avoid for new applications — v1 v1 leaks the MAC address of the generating machine, which is a privacy and security issue. If you need time-ordered UUIDs (the main reason people used v1), use v7 instead — same ordering property, no privacy cost. The only reason to use v1 today is interoperability with a legacy system that requires it.
• Common mistake Choosing v1 for sortability because v7 didn't exist when you learned about UUIDs. v7 is from 2024 (RFC 9562); content written before then often recommends v1 for ordering. That advice is now outdated. v7 supersedes v1 in every dimension that matters.

UUIDs aren't the only option. Several alternatives have emerged that solve specific problems UUIDs don't — shorter representation, URL-safety, faster database performance. Knowing the tradeoffs helps pick the right one:

• Auto-incrementing integers What relational databases give you by default. Pros: shortest possible (typically 4–8 bytes), perfectly sortable, fastest in indexes. Cons: requires central coordination (a single source of truth for the next number), trivially enumerable (`/user/1`, `/user/2`, ...), and not portable across systems. Use when: single-database systems with no enumeration concerns. Don't use when: distributed systems, public-facing IDs.
• UUID v4 (random) 36 chars. No coordination needed. Not sortable. Not enumerable. The historical default for distributed systems. Slight database-performance penalty for primary keys at high insert volume.
• UUID v7 (timestamp + random) 36 chars. Sortable by creation time. Not enumerable (the random suffix prevents enumeration despite the timestamp prefix). Modern best practice. Strictly better than v4 for any new application that supports it.
• ULID (Universally Unique Lexicographically Sortable Identifier) 26 chars (Crockford Base32 encoding — case-insensitive, no I/L/O/U to avoid ambiguity). 48-bit timestamp + 80-bit random. Sortable, URL-safe. Effectively the same idea as UUID v7, predates v7 by several years. Use if you specifically want the shorter Base32 representation; otherwise v7 is more standard.
• NanoID 21 chars default (configurable). URL-safe alphabet. Random — no time component, not sortable. About 30% shorter than UUID with similar collision resistance. Use when: you want URL-friendly IDs and don't need sortability. Common in web apps for slug-style IDs.
• KSUID (K-Sortable Unique ID) 27 chars (Base62). 32-bit timestamp + 128-bit random. Sortable. Used heavily at Segment (Twilio). Similar concept to UUID v7 but with second-level timestamp precision and a different encoding. Niche outside that ecosystem.
• Snowflake (Twitter) 64-bit integer (not a string). Encodes timestamp + worker/datacenter ID + sequence number. Pros: short, sortable, fits in a BIGINT column. Cons: requires worker-ID coordination (each ID-generating service needs a unique worker ID), which kills the 'no coordinator' benefit. Use when: you have a coordinator anyway and want compact numeric IDs.
• CUID2 Newer (2022) alternative explicitly designed to address UUID v4's weaknesses. Variable length, collision-resistant, fingerprint-resistant. Niche but growing. Worth considering for new web applications where UUID feels heavyweight.

A UUID is fundamentally 128 bits. How you display or store those bits is a separate decision — and the right choice depends on whether you optimize for readability, URL-safety, storage size, or compatibility.

• Canonical hex with dashes — 36 chars `f47ac10b-58cc-4372-a567-0e02b2c3d479`. The standard format from RFC 4122. Always lowercase per the spec, though uppercase is widely accepted and Microsoft's GUID format defaults to uppercase. What you'll see in 99% of APIs and database outputs.
• Hex without dashes — 32 chars `f47ac10b58cc4372a5670e02b2c3d479`. Equivalent to the canonical form; some APIs and storage systems prefer this. Saves four bytes per UUID. Some libraries default to this for URL paths.
• Uppercase — Microsoft GUID style `F47AC10B-58CC-4372-A567-0E02B2C3D479`. Functionally identical to lowercase; some Windows-ecosystem tools emit and expect uppercase. Use the case your downstream system expects; both are valid input formats almost everywhere.
• Base64 — 22 chars (URL-safe variant) Encoding the raw 16 bytes as Base64 (with `-` and `_` instead of `+` and `/`, and no padding) gives you a 22-character string — almost 40% shorter than the canonical form. Used in some APIs for compact URLs (Stripe-style 'cus_...' IDs are a variant of this idea). Tradeoff: less readable, harder to copy/paste accurately.
• Binary — 16 bytes The raw 128 bits. Most efficient storage. Most relational databases have a native UUID column type that stores 16 bytes internally (Postgres `uuid`, MySQL `BINARY(16)`). Always store UUIDs as binary if your database supports it — never as `VARCHAR(36)` (more than double the storage, slower indexes, looser type safety).

For programmatic UUID generation — seeding test data, build pipelines, fixture generation, idempotency keys in distributed jobs — every option is available as JSON API.

// Single v4 UUID
const res = await fetch(
  'https://api.domainscan.in/v1/uuid?version=v4'
);
const data = await res.json();
console.log(data.uuids[0]); // 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

// Bulk: 50 v7 UUIDs, uppercase, no dashes
const batch = await fetch(
  'https://api.domainscan.in/v1/uuid' +
  '?version=v7&count=50&uppercase=true&dashes=false'
).then(r => r.json());

console.log(batch.uuids.length); // 50
console.log(batch.uuids[0]);     // '018F4B...' (timestamp-prefixed, sortable)

// Deterministic v5 from namespace + name
const v5 = await fetch(
  'https://api.domainscan.in/v1/uuid' +
  '?version=v5&namespace=6ba7b810-9dad-11d1-80b4-00c04fd430c8' + // DNS namespace
  '&name=example.com'
).then(r => r.json());

console.log(v5.uuids[0]);  // Always the same UUID for example.com under DNS namespace

// For local-only / client-side use, the Web Crypto API plus a small library
// (e.g. `uuid` on npm) is faster and never makes a network call:
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // RFC 9562 v7 UUID, no network round-trip

{
  "success": "boolean",
  "uuids":   ["string"],
  "version": "v1 | v3 | v4 | v5 | v7",
  "count":   "number (1–100)",
  "options": {
    "uppercase": "boolean",
    "dashes":    "boolean"
  },
  "time":    "number (generation time in ms)"
}

// Request parameters
{
  "version":   "string (required: v1, v3, v4, v5, v7)",
  "count":     "number (optional: 1–100, default 1)",
  "uppercase": "boolean (optional: default false)",
  "dashes":    "boolean (optional: default true)",

  // v3 and v5 only:
  "namespace": "string (required for v3/v5: a namespace UUID)",
  "name":      "string (required for v3/v5: name to hash with the namespace)"
}

// Standard namespace UUIDs from RFC 4122 (for v3 and v5):
// DNS:    6ba7b810-9dad-11d1-80b4-00c04fd430c8
// URL:    6ba7b811-9dad-11d1-80b4-00c04fd430c8
// OID:    6ba7b812-9dad-11d1-80b4-00c04fd430c8
// X.500:  6ba7b814-9dad-11d1-80b4-00c04fd430c8

Six patterns we see most often:

• What's the difference between UUID and GUID? Nothing. GUID (Globally Unique Identifier) is Microsoft's name for the same concept. The format is identical, the standards are the same, and they're freely interchangeable. You'll see 'GUID' in Microsoft and Windows documentation and 'UUID' almost everywhere else.
• What's the difference between UUID v4 and v7? v4 is 122 bits of pure random data. v7 is a 48-bit Unix-millisecond timestamp followed by 74 random bits. The practical difference: v7 UUIDs sort chronologically (newer UUIDs sort after older ones), which makes them dramatically better as database primary keys. For most new applications, v7 is the right default; v4 is the right default only for compatibility with older systems.
• Are UUIDs really unique? What's the collision probability? v4 UUIDs have 122 bits of randomness. By the birthday-problem math, you'd need to generate ~2.7 × 10^18 UUIDs to have a 50% chance of one collision. For comparison: if every human on Earth generated one UUID per second for 10,000 years, the probability of any collision would still be effectively zero. UUIDs aren't 'usually unique' — they're cryptographically unique for any realistic scale.
• Is UUID v4 truly random? Can it be predicted? v4 UUIDs use the platform's cryptographically secure random number generator (CSPRNG) — `crypto.getRandomValues()` in browsers, `crypto.randomBytes()` in Node, `/dev/urandom` on Unix. These are designed to be unpredictable even to an attacker who knows previous outputs. v4 UUIDs are safe to use as security tokens, session IDs, or anywhere unpredictability matters.
• Why use UUIDs instead of auto-incrementing integers? Three reasons: (1) no central coordinator needed — generation works in any distributed system. (2) resistance to enumeration attacks — `/users/123` leaks customer count; `/users/<uuid>` reveals nothing. (3) portability — UUIDs from different systems can be merged without renumbering. The tradeoff: UUIDs are longer (36 chars vs. ~10 chars for an integer) and slightly slower in indexes if you pick the wrong version. With v7, even that tradeoff mostly disappears.
• Should I use UUIDs as database primary keys? Yes, with the right version. v7 UUIDs work well as primary keys — sortable, no enumeration risk, no central coordinator. v4 UUIDs as primary keys can cause B-tree index fragmentation at high insert volume, which manifests as slow inserts and bloated indexes. Always store as the database's native UUID type (Postgres `uuid`, MySQL `BINARY(16)`), never as `VARCHAR(36)`.
• Can I shorten a UUID without losing uniqueness? Yes — encode the 16 bytes as Base64 (URL-safe variant) for 22 chars instead of 36, or as Base32 for 26 chars (the ULID format). The uniqueness comes from the 128 bits of data, not from the encoding. What you can't do safely is truncate — taking the first 8 chars of a UUID isn't 'a shorter UUID', it's a 32-bit value with a much higher collision rate.
• What's the difference between UUID v3 and v5? Both are deterministic UUIDs generated by hashing a namespace UUID + a name string. v3 uses MD5; v5 uses SHA-1. v5 is generally preferred because SHA-1 is stronger than MD5, but for namespace-UUID purposes (which aren't a security-sensitive use), both work. Most modern code defaults to v5; v3 is mostly preserved for backward compatibility.