What is a UUID Generator?
A UUID (universally unique identifier), or GUID, is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups — eight, four, four, four, twelve. Uniqueness needs no coordination: no central registry, no shared counter, no round trip to a database. That is why UUIDs became the default identifier for database keys, distributed systems, request tracing and filenames.
This generator produces two versions from RFC 9562. UUID v4 is 122 random bits, which makes accidental collisions effectively impossible even across unrelated machines. UUID v7 puts a 48-bit Unix millisecond timestamp first and 74 random bits after it, so tokens generated later always sort later as text — the property that keeps a B-tree index from fragmenting the way purely random keys do.
Randomness comes from the browser's crypto.getRandomValues, the same operating-system CSPRNG used for TLS keys and session cookies, not from Math.random.
How to generate UUIDs
- Choose the version. v4 when you only need uniqueness, v7 when the identifier should also sort by creation time.
- Set how many you need, anywhere from 1 to 1,000, to build a seed list in one pass.
- Decide on the formatting: uppercase, no hyphens, or wrapped in braces to match the representations used by SQL Server, .NET and Python's uuid module.
- Press Generate. Copy all puts the newline-separated list on your clipboard, Download .txt saves it as a file, and clicking any of the short chips copies that single identifier.
- Generate again as often as you like — there is no quota, because nothing is requested from a server.
UUID Generator limits and rules
| Item | Limit |
|---|---|
| Format | 8-4-4-4-12 hex digits — 36 characters with hyphens, 32 without |
| UUIDv4 randomness | 122 bits; version and variant bits are fixed |
| UUIDv7 layout | 48-bit millisecond timestamp, then 74 random bits |
| Maximum batch size | 1,000 identifiers per generation |
| v4 collision odds | About 50% only after 2.71 × 10¹⁸ identifiers |
| v7 ordering | Millisecond-precise; ids made in the same millisecond are ordered by their random bits |
| Version digit | The 13th hex digit is 4 or 7 |
| Variant digit | The 17th hex digit is always 8, 9, a or b (RFC 4122 variant) |
When to use it
- Primary keys in a database: v7 for insert-heavy tables because sequential keys keep the index compact, v4 when order is irrelevant.
- Distributed systems and microservices that need to mint identifiers without a round trip to a central authority.
- Test fixtures and seed data — generate a thousand records' worth of ids in one click.
- Idempotency keys and correlation ids for APIs, so a retried request can be recognised as the same operation.
- Naming uploaded files, log entries or temporary directories without a race between concurrent processes.
Is it private?
Everything runs inside your browser. Your text and files are never uploaded, never stored and never seen by anyone else — including me. You can use the tool with the network tab open and watch no request leave the page. Closing the tab erases the input.
Frequently asked questions
Use v7 whenever the identifier lands in a database index or gets sorted, because its timestamp prefix keeps inserts sequential. Use v4 when you are storing the id as a binary or string column that is never ordered and you want maximum randomness.
No. 122 random bits is strong entropy, but UUIDs are routinely logged, echoed in URLs and returned in error messages, so they leak. Generate a dedicated secret token with a password or token generator instead of reusing an identifier.
Those bits are the RFC 4122 variant field. RFC 9562 keeps the same layout so older parsers still recognise the value as a standard UUID; the remaining 62 random bits in that group are unaffected.
No. They are built with the browser's own cryptographic random source, so the identifiers exist only in your tab and nothing is logged anywhere.
For v4, no: the chance of even one duplicate in a thousand draws is roughly 1 in 10³³. For v7 the timestamp differs per identifier, so duplicates would additionally require identical random bits — the same practical impossibility.
Related tools
Written and maintained by Md. Nur Hossain Repon.