UUID Generator

What a UUID is

A UUID — Universally Unique Identifier — is a 128-bit number written as 32 hexadecimal characters split by hyphens into a 8-4-4-4-12 pattern. The defining property is in the name: every UUID generated by any system anywhere should, in practice, be different from every other one. Not technically guaranteed unique; statistically unique to a degree that you can treat as guaranteed.

Here's a sample, freshly generated:

The format is fixed: 8 hex chars, hyphen, 4 hex chars, hyphen, 4 hex chars, hyphen, 4 hex chars, hyphen, 12 hex chars. The hyphens carry no information — they're there to make the value readable. The actual data is the 32 hex characters, encoding 128 bits.

The UUID Generator on this page produces UUID v4 — the random-only variant of the spec. That's the variant you want for ID generation in basically every modern application, unless you have a specific reason to use something else (and the FAQ below covers when you might).

How to use the UUID Generator

The widget produces one UUID v4 at a time. Steps:

1. Open the page. A UUID appears automatically — the tool generates one on load so you have something to grab immediately.
2. Click Generate UUID to roll a fresh one. Each click produces a new, independent random 128-bit value.
3. Click Copy to Clipboard to paste the UUID into whatever you're working on — a config file, an API request, a database seed.

The generation runs entirely in your browser using JavaScript's built-in random source. Nothing leaves the page, and there's no rate limit. Need 50 UUIDs for a test fixture? Click Generate 50 times, or write a tiny script in your browser console using crypto.randomUUID() — same output format, same standard.

How v4 actually works

UUID v4 takes 128 bits of randomness and stamps two small regions with fixed values that say "this is a v4 UUID":

• The 13th hex character is always 4 — this marks the version.
• The 17th hex character is always one of 8, 9, a, or b — this marks the variant (RFC 4122).
• The other 122 bits are random.

You can spot the version marker in any UUID v4. In f47ac10b-58cc-4372-a567-0e02b2c3d479, the bolded 4 and the leading nibble of a567 are the version and variant markers. Everything else is randomness.

So a UUID v4 has 122 bits of entropy, not 128. The other 6 bits are protocol overhead. That's still an astronomical number — 2^122 is about 5.3 × 10^36. For comparison, the number of grains of sand on Earth is estimated at 7.5 × 10^18. You'd run out of grains of sand on every beach a quintillion times before you'd run out of distinct UUIDs.

Collision probability — what "unique" actually means

UUIDs aren't guaranteed unique. They're probabilistically unique, and the probability is so close to 1 that practical software treats them as guaranteed. The math is worth understanding once.

The birthday paradox gives the rule of thumb: for a random ID with N bits of entropy, you need to generate roughly 2^(N/2) of them before there's a meaningful chance any two collide. For UUID v4 with 122 bits of entropy, that's 2^61 — about 2.3 × 10^18 UUIDs — before you reach a 50/50 chance of a collision.

This is why production systems use UUIDs as primary keys for distributed databases, message IDs across queues, session tokens, request correlation IDs, and so on. You don't need a central authority handing out IDs and checking for duplicates. Every node generates its own, and the math handles the uniqueness.

UUID versions — when to use which

The spec defines several UUID versions, each with different tradeoffs. The Microapp generator produces v4 because that's what 95% of use cases need. Here's the broader picture:

The two versions you'll encounter most in modern code are v4 (when sort order doesn't matter — most app code) and v7 (when sort order does matter — typically database primary keys, where time-ordered IDs improve B-tree insert performance and let you trivially shard by time).

If you're starting a new system today and reaching for "give me a unique ID," v4 is the safe default. If your database performance profile shows lots of random-insert overhead on UUID primary keys, v7 is the upgrade — but you don't need to make that call on day one.

Worked example: seeding a development database

Say you're building a task-tracking app and need to seed a local PostgreSQL database with 5 sample tasks. Your tasks table uses UUID primary keys. You need 5 UUIDs.

Click Generate five times in the UUID Generator. You'll get something like:

• f47ac10b-58cc-4372-a567-0e02b2c3d479
• a3c8e1d2-7b4f-4a89-91e0-2f6d4c8e7b1a
• e9d2c5b1-4f8a-4d3c-b9e5-1a8d3f5c7e2b
• b1c4e8d3-6a9f-4e2b-8d7c-3f1e5a8b9c4d
• d8a3f1b2-9c4e-4f7b-a2e5-6d1c4b8a9e3f

Paste them into your seed file:

These UUIDs will never collide with anything else in your database, or with anything anyone else generates anywhere, ever. You don't need to coordinate IDs with a teammate, check a sequence, or worry about gaps. That's the whole point of using UUIDs instead of integer auto-increment IDs in distributed or multi-developer systems.

Common UUID mistakes

UUIDs are simple enough that the usual mistakes happen at the integration points, not in the generation itself:

• Treating the hex characters as case-sensitive. They aren't. F47AC10B-... and f47ac10b-... are the same UUID. Most systems normalize to lowercase. If you compare two UUID strings directly without normalizing, you'll get false negatives.
• Storing UUIDs as 36-char strings in databases that have a native UUID type. PostgreSQL, MySQL 8+, and SQL Server all have a native UUID/uniqueidentifier type that stores the value in 16 bytes instead of 36. The native type is 2.25× smaller on disk, and indexes are faster. Use it.
• Using UUID v4 in a URL when you wanted something shorter. A UUID v4 is 36 characters with hyphens, 32 without. If your use case needs a shorter URL slug, you want something like a random short string or a base62-encoded counter, not a UUID. UUIDs are for internal uniqueness, not for user-facing identifiers.
• Using Math.random() to generate UUIDs in security contexts. Math.random() is not cryptographically secure — its output is predictable given enough samples. For session tokens, password reset links, API keys, or anything else where guessability matters, use crypto.randomUUID() in browsers and Node.js, or your language's CSPRNG. The UUID Generator on this page uses Math.random() for speed, which is fine for the seeding/testing use cases UUIDs are usually generated for in a UI like this — but understand the distinction for security-sensitive code.
• Sorting by UUID v4 expecting time order. v4 is pure random — it has no time component, so sorting it gives you alphabetical order of random hex, not creation order. If you want creation-order sorting, use UUID v7 or store a separate created_at timestamp.

Related tools

UUIDs are one piece of a larger family of identifier and randomness tools. A few that pair naturally:

• Password Generator — for human-readable random strings (with options for length, character classes, and pronounceability). Use this when you want randomness for a user-facing credential, not a system-facing identifier.
• MD5 Hash Generator — useful when you need a deterministic 128-bit fingerprint of some input rather than a random one. (For new code, prefer SHA-256 — MD5 has known collision attacks.)
• SHA-256 Generator — the modern replacement for MD5 when you need a content-derived fingerprint.
• Random Number Generator — for integers within a range, not 128-bit identifiers. Different problem, different tool.
• JSON Formatter — for cleaning up the JSON payloads that UUIDs typically travel inside.

Frequently asked questions

Is the UUID I get from this page truly random?

It's generated with JavaScript's Math.random(), which uses a pseudo-random number generator under the hood. For seeding test data, generating IDs in development, or any non-security-sensitive use, this is fine — the output is statistically random enough that collisions are infeasible. For security-sensitive uses (session tokens, password reset links, API keys), generate UUIDs in your application code using crypto.randomUUID() (browser and Node.js) or your language's equivalent cryptographically secure generator instead. The output format is identical; only the underlying randomness source differs.

Will two UUIDs ever collide?

In any realistic application, no. With 122 bits of randomness, you'd need to generate about 2.3 quintillion (2.3 × 10^18) UUIDs before a 50% chance of any two colliding. Even at a million UUIDs per second across a fleet of servers, the math says you'd run for thousands of years without a collision. The standard treats UUIDs as effectively unique because, for engineering purposes, they are.

Why are UUIDs 36 characters? Couldn't they be shorter?

The 128 bits of data encode to 32 hex characters, plus 4 hyphens for readability. The hyphens are cosmetic — you can store and transmit UUIDs as the 32-char compact form (no hyphens) or as 16 raw bytes if your system supports it. PostgreSQL stores UUIDs as 16 bytes natively. Most APIs return the 36-char hyphenated form because it's human-readable. If you want something shorter for a URL, encode the same 128 bits in base64 (22 chars) or base62 (~22 chars) — but you're no longer producing a "UUID" by the spec at that point, just a custom random ID.

What's the difference between UUID v1 and v4?

v1 encodes the current timestamp and the generating machine's MAC address into the UUID. That made it useful in early distributed systems (you could tell where and when an ID was created) but it leaks both pieces of information. v4 is pure randomness — no time, no machine identity, just 122 random bits. v4 is the default for almost every modern use because it doesn't leak anything and uniqueness is statistical rather than coordination-dependent. If you need time-sortable UUIDs without the MAC leak, use v7 (Unix timestamp + random bits) — it's the modern equivalent of v1's sort-by-time property.

When should I use UUID v7 instead of v4?

When you're using UUIDs as database primary keys and you've measured insert performance as a bottleneck. v4's randomness scatters new rows across the B-tree index, causing more page splits and worse cache behavior than time-ordered IDs. v7 starts with a millisecond timestamp, so new rows append to the end of the index — much better insert performance and the same uniqueness guarantees. For app-level IDs that aren't database keys, v4 is still fine.

Can I generate UUIDs from a specific input (like a username)?

Yes — that's what UUID v3 (MD5-based) and v5 (SHA-1-based) are for. You hash a namespace UUID plus an input string, and you get a deterministic UUID. Same input, same output, every time. Useful when you want a stable ID for an entity that doesn't have an ID of its own — for example, "what's the canonical UUID for the domain example.com?" Prefer v5 over v3 in new code, because SHA-1 has fewer known weaknesses than MD5 (though both are now broken for cryptographic uses).

Can I generate UUIDs programmatically without this page?

Every modern language has a UUID library or built-in. In JavaScript: crypto.randomUUID(). In Python: import uuid; uuid.uuid4(). In Go: the github.com/google/uuid package. In Java: UUID.randomUUID(). In Ruby: require "securerandom"; SecureRandom.uuid. This page is for the moments when you don't have a terminal open and you need one UUID right now to paste somewhere.

Are UUIDs case-sensitive?

No. F47AC10B-... and f47ac10b-... represent the same value. Most systems normalize to lowercase, including PostgreSQL's native UUID type. If you're comparing UUID strings as plain text, normalize the case first to avoid false negatives.

Is there a maximum number of UUIDs I can generate?

Practically unlimited. Click Generate as many times as you want. Each click produces an independent random 128-bit value with no server round trip. There's no rate limit because there's no server in the loop — the generation happens in your browser using JavaScript's built-in randomness source.

Why does the page generate a UUID automatically when it loads?

Because the most common reason someone visits a UUID generator is "I need one UUID right now." Auto-generating on load means it's already there when you arrive — you click Copy and you're done. If you want a fresh one (in case the auto-generated one is somehow on your screen for too long, or you just want a different value), the Generate button is one click away.