About the UUID Generator
This free UUID generator creates random version 4 UUIDs (also called GUIDs) — universally unique identifiers used in databases, APIs, log files and distributed systems. Generate one or a whole batch and copy them with a click.
They are generated in your browser using crypto.getRandomValues, the same cryptographically secure random source used for encryption keys. Nothing is requested from a server, so every UUID you see here has existed nowhere else.
What a UUID is
A UUID is a 128-bit number, written as 32 hexadecimal digits in five groups separated by hyphens:
f47ac10b-58cc-4372-a567-0e02b2c3d479
The grouping is 8-4-4-4-12, and the total length is always 36 characters including the hyphens.
The point of it is generating a unique ID without asking anyone. A database can hand out 1, 2, 3… because it is the single authority on what comes next. But when two phones are creating records offline, or twelve servers are inserting rows at once, or you need an ID *before* the row exists, there is no authority to ask. A UUID solves that by being so large and so random that a collision is not worth thinking about.
Version 4, and the two digits that give it away
There are several UUID versions. Version 4 is the random one, and it is what almost everyone means by "a UUID".
You can read the version straight out of the string. In f47ac10b-58cc-4372-a567-0e02b2c3d479:
- The first digit of the third group is the version — a 4 here
- The first digit of the fourth group is the variant — always 8, 9, a or b
Those two positions are fixed, which leaves 122 bits of actual randomness rather than 128.
The other versions you may meet: v1 encodes the timestamp and the machine's MAC address, which makes it sortable but leaks where and when it was made. v7, standardised in 2024, is the modern answer — a timestamp at the front and randomness after it, so IDs sort by creation time without leaking hardware details. If you are choosing today and database ordering matters, v7 is worth knowing about.
Are they really unique?
Not guaranteed, but the numbers are absurd enough that it does not matter.
122 random bits gives about 5.3 × 10³⁶ possible values. To reach a 50% chance of a single collision you would need to generate roughly 2.7 × 10¹⁸ UUIDs — 2.7 quintillion.
Put concretely: generating a billion UUIDs every second, it would take about 85 years to reach a 50% chance of one duplicate anywhere in the set. For any real application, the risk is smaller than the risk of your storage silently corrupting the value.
The one real caveat is the quality of the randomness. A UUID from a weak random source is not unique in the way the maths promises — there have been real bugs where a predictable generator produced repeats. This tool uses the browser's cryptographic generator, not Math.random().
A UUID is not a secret
Worth stating plainly, because it is misused in both directions.
A v4 UUID is unpredictable, so it is reasonable as an unguessable URL — a share link or a password-reset token. But it is not designed as a security primitive, it carries no expiry, and it is frequently logged, cached, put in analytics and pasted into chat. Treat it as an identifier that happens to be hard to guess, not as a credential.
And the reverse: do not assume a UUID hides anything. A v1 UUID contains a timestamp and a MAC address in plain sight. If you inherited IDs from somewhere and they start with a version 1, they are telling anyone who reads them when and where they were created.
Where you will use them
- Database primary keys — especially when rows are created on several machines at once
- Offline-first apps — a phone can create records with no connection and sync later without renumbering
- API request IDs — tracing a single request through many services in the logs
- File and upload names — avoiding collisions without trusting the user's filename
- Message deduplication — an idempotency key so a retried request is not processed twice
- Share links — an unguessable URL for a document or an invitation
- Test fixtures — unique values that will never clash with real data
How to use it
- Choose how many you need
- Generate — fresh UUIDs appear
- Copy — copy a single UUID or the whole list
Good to know
- Case does not matter, but lowercase is the convention and what this tool produces. Some systems compare UUIDs as plain strings, where A and a are different — so be consistent.
- The hyphens are formatting. Many systems store the 32 digits with no hyphens, or as 16 raw bytes. Same value, different presentation.
- As a database key they cost something. A UUID is 16 bytes against 4 or 8 for an integer, and random values scatter writes across a B-tree index instead of appending at the end. On a large, write-heavy table that is measurable — which is exactly the problem v7 was designed to fix.
- Do not use them as passwords. They are unpredictable, but they are identifiers, and they end up in logs and browser history.
- "GUID" is Microsoft's name for the same thing. In .NET and SQL Server you will see GUID; it is the same 128-bit value.
- The nil UUID is all zeros — 00000000-0000-0000-0000-000000000000. It usually means "none" or "not set", so it is worth recognising.
Common questions
What is a UUID and what is it for?
A UUID is a 128-bit identifier written as 36 characters, such as f47ac10b-58cc-4372-a567-0e02b2c3d479. Its purpose is to let anything generate a unique ID on its own, with no central counter to consult. That matters when records are created on several servers at once, on a phone that is offline, or before the row exists in the database at all.
Are UUIDs guaranteed to be unique?
No, but the probability of a clash is negligible. A version 4 UUID has 122 random bits, giving around 5.3 × 10³⁶ possibilities. You would need to generate about 2.7 quintillion of them before reaching a 50% chance of a single duplicate. At a billion per second that is roughly 85 years.
What is the difference between UUID and GUID?
None in practice. GUID is Microsoft's name for the same 128-bit identifier and you will see it throughout .NET and SQL Server. The only wrinkle is that some Microsoft tooling displays a GUID wrapped in braces, like {f47ac10b-...}, and a few older APIs order some bytes differently when converting to raw binary.
Which UUID version should I use?
Version 4 for general use — it is fully random and gives away nothing about where or when it was made. Consider version 7 if these IDs will be database primary keys, since it puts a timestamp at the front so the values sort by creation time and index far more efficiently. Avoid version 1 for anything public, because it embeds a MAC address and a timestamp.
Can I use a UUID as a security token?
For an unguessable link it is acceptable, since a v4 UUID cannot realistically be predicted. But it is an identifier rather than a credential: it never expires, it cannot be revoked on its own, and it tends to end up in server logs, analytics and browser history. For real authentication use a purpose-built token with an expiry.
Are these UUIDs generated on your server?
No. They are created in your browser by crypto.getRandomValues, the cryptographically secure generator built into every modern browser. No request is made and nothing is recorded, so you can generate them with your connection switched off.
Related tools
- Password Generator — the same secure random source, for secrets rather than identifiers
- Hash Generator — MD5, SHA-1 and SHA-256 for fingerprinting data
- Random Number Generator — random numbers in a range you choose
- Timestamp Converter — read the timestamp inside a v1 or v7 UUID