Free UUID / GUID Generator Online
Generate UUID v1 (timestamp-based) and UUID v4 (random) instantly. Bulk generate up to 1000 UUIDs with format options. 100% client-side — your data stays private.
What is a UUID? A UUID is a 128-bit identifier written as 32 hexadecimal digits in five hyphen-separated groups, 8-4-4-4-12. It is designed to be generated independently on any machine without a central authority and still be unique, which is what makes it useful across distributed systems. Version 4 fills 122 of those bits with random data; version 1 derives most of them from a timestamp. GUID is Microsoft's name for the same thing.
How to Use the UUID Generator
- Choose the version — v4 is the right default for almost everything — it is pure randomness with no ordering and nothing derived from your machine. Pick v1 only when you need identifiers that sort roughly by creation time.
- Set how many you need — Anything from 1 to 1000 in a single batch. Each value is generated independently, so a batch of a thousand is exactly as safe as a thousand separate clicks.
- Pick the letter case — Lowercase is the canonical output form specified by the standard and what you should store. Uppercase exists because some Microsoft and legacy tooling displays GUIDs that way; comparisons should be case-insensitive either way.
- Decide on hyphens — With hyphens gives the familiar 36-character form. Without gives a 32-character string, which is more compact in a URL or a filename — but strip them consistently, because a system expecting one form rarely accepts the other.
- Generate and copy — Use the button on any row to copy a single value, or Copy All to take the whole batch as newline-separated text ready to paste into a seed file or spreadsheet.
-
Store it as 128 bits where you can — In a database, a native
uuidorBINARY(16)column uses 16 bytes; the same value asCHAR(36)uses 36 and makes every index larger. The saving compounds across a large table and its indexes.
How a UUID Is Built
A UUID is not a random string that happens to be 36 characters long. It is a fixed 128-bit layout in which specific bits are reserved, and the reserved bits are what let any program recognise which kind of UUID it is holding. Two fields are constant across every version: four bits identify the version, and the top bits of the next byte identify the variant.
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
The digit at position M is the version number — a literal 4 in every v4 value and
1 in every v1 value. The digit at N encodes the variant and is always one of
8, 9, a or b for the standard layout. If you look at a UUID and
those two positions do not fit, you are looking at a random hex string rather than a conforming UUID.
Field Layout by Version
| Group | Digits | In version 4 | In version 1 |
|---|---|---|---|
| 1st | 8 | Random | Low 32 bits of the timestamp |
| 2nd | 4 | Random | Middle 16 bits of the timestamp |
| 3rd | 4 | Version 4 + 12 random bits | Version 1 + high timestamp bits |
| 4th | 4 | Variant bits + 14 random bits | Variant bits + clock sequence |
| 5th | 12 | Random | Node field |
Where the Randomness Comes From
Version 4 values here are produced by requesting 16 bytes from crypto.getRandomValues(), the browser's
cryptographically secure random source, and then overwriting the version and variant bits. That leaves
122 random bits, or about 5.3 × 1036 distinct possible values — enough that collisions are
not a practical concern for any realistic volume of identifiers. The distinction from Math.random() matters:
that generator is fast but predictable from its output, so identifiers built on it can be guessed. This tool does not use
it for v4.
Version 1 encodes the number of 100-nanosecond intervals since 15 October 1582, the date the Gregorian calendar was adopted, which is why v1 values sort roughly into creation order. Historically the last group held the machine's MAC address, and that is the origin of v1's reputation for leaking hardware identity. This generator does not do that: the node field is filled with random bytes instead, which the specification permits, so nothing about your device is embedded. Note also that a browser clock reads in milliseconds, so several v1 values generated in the same millisecond share a timestamp and differ only in their random portion.
Choosing a Version for Database Keys
The trade-off is ordering. Because v4 values are random, consecutive inserts land at scattered points in a clustered index, which causes page splits and index fragmentation on engines that physically order rows by primary key — the classic symptom of switching a busy InnoDB table to random UUID keys. Time-ordered identifiers avoid that by appending in sequence.
RFC 4122, which defined v1 and v4, was superseded by RFC 9562 in 2024. It keeps the older versions valid and adds version 7, which puts a millisecond Unix timestamp in the leading bits and random data in the rest. That gives you insert locality without exposing a MAC address, and it is now the recommended choice for new database-key work — use the UUID v7 Generator for those.
A UUID is an identifier, not a secret. A v4 value is unpredictable enough that guessing one is impractical, but it is designed to be shared, logged and printed in URLs — so do not use one as a session token, password-reset code or API key, where you also need revocation, expiry and a controlled comparison. Generate those with the Password Generator instead.
Frequently Asked Questions
Version 4 is 122 bits of random data, so two values generated a second apart have no relationship and sort in no meaningful order. Version 1 derives its first three fields from a timestamp, so values sort roughly by creation time. Classic v1 implementations put the machine's MAC address in the final field, which is why it has a reputation for leaking hardware identity; this generator fills that field with random bytes instead. Choose v4 unless you specifically need time ordering.
Yes for the layout. Both versions set the version nibble and the variant bits exactly as the specification requires, so any parser will identify them correctly as v4 or v1. RFC 4122 originally defined both; it was superseded by RFC 9562 in 2024, which keeps them valid and adds the newer versions 6, 7 and 8.
For version 4, negligible at any realistic scale. With 122 random bits there are roughly 5.3 × 1036 possible values, and the practical risk depends far more on the quality of the random source than on the count. Because this tool draws from crypto.getRandomValues() rather than Math.random(), that source is a cryptographically secure generator. Systems that have hit real UUID collisions almost always had a broken or unseeded RNG, not bad luck.
Up to 1000 per batch, with no daily cap — run as many batches as you need. Each value is drawn independently, so a batch of a thousand is exactly as unique as a thousand single generations. For millions of identifiers, generate them in your application rather than pasting them, since every mainstream language has a UUID library built in.
No. Generation happens entirely in your tab and no request carries the results anywhere, so nobody else has ever seen the values you produce. Only your settings — version, count, case and hyphen choice — are kept in the page URL so a configuration can be reopened. The identifiers themselves are never placed in the address bar.
It is not the right tool, even though a v4 value is unpredictable. Credentials need expiry, revocation and constant-time comparison, and treating an identifier as a secret tends to mean it ends up in URLs, logs and referrer headers where identifiers legitimately belong. Use a purpose-built random secret for authentication and keep the UUID for identifying the row.
It depends on your engine and your write volume. UUIDs let independent services mint keys without coordination and stop row counts leaking through sequential IDs. The cost is that random v4 keys scatter inserts across a clustered index, causing page splits and fragmentation on engines that order rows physically by key. If that applies to you, use a time-ordered UUID v7 and store it as 16 binary bytes rather than a 36-character string.
Use Cases
Database Primary Keys
Generating unique database primary keys with UUIDs ensures no collisions in distributed systems and microservices.
Session Identifiers
Creating session identifiers helps web applications track user sessions securely without exposing sequential IDs.
API Request IDs
Producing API request IDs enables accurate logging, debugging, and tracing of requests across distributed systems.
Bulk Test Data IDs
Bulk generating test data IDs accelerates development and testing by providing unique identifiers for sample datasets.
Unique Transaction References
Creating unique transaction references ensures financial records are traceable and auditable in payment systems.