HandyTools Hub

UUID Generator

Generate random UUIDs (v4) instantly.

5
1 100

Format

Generated UUIDs

f3cb4425-8512-495d-b25a-c3089db3195a
03b98ae9-8017-4212-b4ca-6a6db6353981
e22aa754-4402-45bf-b28b-c1515852e418
58a45390-6795-45ad-904b-cfa366f736cc
85744088-6017-444a-ac34-12d1f0f6dac5

The UUID Generator creates version-4 universally unique identifiers in batches of up to 100, with optional uppercase output and dash-free formatting, plus one-click copy or text download. It is built for developers who need identifiers for database rows, API resources, files, and test fixtures — without writing a script or trusting an online service that might log what it generates. Every value is produced locally with the browser’s cryptographically secure random generator.

How to Use

  1. Choose how many UUIDs you need, from 1 to 100. Each click of Generate produces a fresh batch.
  2. Set the format. Uppercase output and dash removal are independent toggles, so you can match the exact shape another system stores.
  3. Generate. All values appear instantly in a list.
  4. Copy or download. Copy a single UUID with its button, use Copy All for the batch, or download the whole list as a text file.

Worked Examples

Example 1 — seeding a database table. A developer needs 25 placeholder rows before a migration test. Generating 25 v4 UUIDs and pasting them into an SQL insert script takes seconds — far faster than writing a loop, and free of the auto-increment collisions that appear when merging data from several environments.

Example 2 — naming uploaded files. Storing user uploads under their original filenames invites collisions and path-traversal problems. A pattern like uploads/<uuid>.jpg guarantees a unique, unguessable name. Note that uniqueness is not security on its own: the UUID should be paired with access control, since anyone who learns the name can request it.

Example 3 — test fixtures. A test suite needs deterministic-looking but distinct IDs for mock users. Generating a batch once and hard-coding them into the fixture file keeps tests reproducible, while the real application continues to mint its own identifiers at runtime.

UUID Versions and Which to Use

A UUID is a 128-bit value, conventionally written as 32 hex digits in five groups: 8-4-4-4-12. The first digit of the third group encodes the version. The common ones:

  • v1 — timestamp plus the generating machine’s MAC address. Ordered but leaks hardware and time information.
  • v3 / v5 — a deterministic hash (MD5 / SHA-1) of a namespace and a name. The same input always yields the same UUID.
  • v4 — 122 random bits. Stateless, leaks nothing, and is what this tool generates.
  • v7 — a Unix millisecond timestamp followed by random bits, standardized in 2024. Sorts by creation time, which makes it the modern choice for database keys.

The practical split: use v4 for identifiers you will not index heavily, and v7 for primary keys in new tables where write throughput and locality matter.

One naming note before you compare formats: Microsoft’s world calls these values GUIDs, and the two terms refer to the same 128-bit structure. A GUID produced by Windows tooling is byte-identical to a UUID; only the conventional text formatting and the name differ. If documentation or a database column says GUID, a generated UUID will fit, as long as both sides agree on dashes and letter case.

How v4 Randomness Works

Of the 128 bits, 4 are fixed to mark the version and 2 to mark the variant, leaving 122 bits of randomness. That yields the collision math above. The quality of those bits depends entirely on the source: crypto.randomUUID() and crypto.getRandomValues() draw from the operating system’s entropy pool, while a quick Math.random()-based generator can be seeded predictably and is unsuitable for identifiers that must never collide.

Common Mistakes and Edge Cases

  • Treating a UUID as a secret. It is an identifier. Use dedicated tokens for credentials and reset links.
  • v4 as a clustered primary key. Random inserts fragment indexes. Store as BINARY(16) and prefer v7 for new high-write tables.
  • Inconsistent formatting. Some systems store uppercase, some strip dashes, some compare case-sensitively. Normalize on one representation before comparing or storing.
  • Assuming “unique” means “verified.” Uniqueness is probabilistic. For safety-critical uniqueness, keep a database unique constraint rather than trusting the generator alone.
  • Generating on the client and trusting it. If identifiers cross a trust boundary, validate and re-issue them server-side; a client can send any string it likes.
  • Confusing UUIDs with ULIDs. ULIDs are a different 128-bit scheme with a sortable timestamp and a more compact Base32 text form. Convert deliberately rather than treating them as interchangeable.

Features

  • Batch generation of up to 100 v4 UUIDs per click
  • Cryptographically secure randomness via the Web Crypto API
  • Optional uppercase output and dash-free 32-character form
  • Copy individual values or the whole list; download as text
  • Works offline with no account and no server round trip
  • 100% client-side — generated values are never transmitted

Use Cases

  • Database records: Unique keys for rows in distributed systems.
  • APIs and resources: Stable identifiers in URLs and payloads.
  • File naming: Collision-free names for uploads and generated assets.
  • Testing: Fixture IDs for mocks, seeds, and sample data.
  • Distributed systems: Identifiers that cannot clash across nodes.

Frequently Asked Questions

Are these UUIDs truly unique?

Version-4 UUIDs carry 122 random bits, giving about 5.3 × 10^36 possible values. You would need to generate roughly 2.7 × 10^18 of them before the chance of any collision reaches 50% — far beyond any realistic workload. In practice the risk comes not from the math but from a weak random source, which is why this tool uses the browser's crypto.randomUUID rather than a pseudo-random function.

Can I make the UUIDs uppercase or remove the dashes?

Yes, both options are built in. Removing dashes gives the bare 32-character hex string some databases prefer; uppercase suits systems that normalize identifiers that way. The underlying value is identical — pick whichever form your target system expects.

Should I use a UUID as a password reset token or API key?

No. A UUID is an identifier, not a secret. It leaks through logs, URLs, referrer headers, and error messages far more often than people expect, and v1/v6 UUIDs can even embed a timestamp and machine identifier. For credentials, generate a dedicated random token (256 bits from a CSPRNG, base64url-encoded) with an expiry and a revocation path.

Which UUID version should I generate?

For general-purpose identifiers, v4 (what this tool produces) is the safe, stateless choice. If the value will be a database primary key, v7 is usually better because its timestamp prefix sorts naturally and keeps index writes sequential. If you need a deterministic ID derived from a name, use v5 rather than generating randomly.

Why does my database slow down with v4 UUIDs as primary keys?

Because v4 is uniformly random, each insert lands at an arbitrary position in a B-tree index instead of appending at the end. That causes page splits, cache misses, and index fragmentation as the table grows. Storing the value as BINARY(16) instead of CHAR(36) helps a lot, and switching new tables to time-ordered v7 UUIDs removes the problem at its root.

Do I need an internet connection to generate UUIDs here?

No. Generation uses the Web Crypto API that ships with your browser and works offline once the page has loaded. Nothing is sent to a server, and the generated values are never stored — reloading the page discards them.

Reviewed by the HandyTools Hub team · Last updated