UUID / GUID Generator
Generate random UUID v4 identifiers with formatting options.
Generating identifiers for test data
Generate one identifier or a batch above. The everyday use in testing is a value guaranteed not to collide with anything already in the database: a fresh order reference, an idempotency key, a correlation id to follow a request through several services, a unique email local part so a sign-up test can run twice in a row.
A UUID is 128 bits rendered as 32 hexadecimal digits in five groups separated by hyphens. Version 4, which this generator produces, fills almost all of those bits randomly, so two generated values colliding is not a practical concern at any volume a test suite will reach.
UUID or GUID
The same thing under two names. UUID is the term used by the standard and by most of the industry; GUID is Microsoft’s name for it and is what you see in .NET and SQL Server documentation. One difference in practice is presentation: the Microsoft ecosystem often shows them in uppercase and sometimes wrapped in braces. Comparing identifiers as raw strings across systems is therefore risky: normalise case before comparing, or a test fails on formatting while the values are identical.
Which version to use
| Version | Built from | Worth knowing |
|---|---|---|
| v1 | Timestamp plus the host MAC address | Leaks the machine and the creation time; avoid in anything user-facing |
| v4 | Random bits | The safe default; no information encoded, no ordering |
| v5 | A namespace and a name, hashed | Deterministic: the same input always gives the same identifier |
| v7 | A timestamp prefix plus random bits | Sorts by creation time, which databases index far more happily |
Two of these are security-relevant. A version 1 identifier in a public API is an information disclosure, because it reveals a hardware address and a precise creation timestamp. And whatever the version, a UUID is unguessable, not secret: an object reachable purely because someone knows its identifier is still an access control defect, just a harder one to stumble upon.
Identifiers as database keys
Random identifiers as a primary key have a cost worth knowing when you are testing performance. Because version 4 values have no order, each insert lands at a random point in the index, which fragments it and slows writes as the table grows: a problem that does not appear in a small test dataset and does appear in production. Version 7, with its timestamp prefix, restores ordering and largely removes the effect. If a system uses random keys and load tests were run against a small table, that is a gap worth raising.
Test cases around identifier handling
- Uppercase and lowercase forms of the same value: does the system treat them as equal?
- A value wrapped in braces, as some Microsoft tooling emits.
- A value with the hyphens removed, which some APIs accept and others reject.
- The all-zero identifier, which frequently means null in practice and is worth testing explicitly.
- A malformed value with one character too many or a non-hex character, to confirm validation exists.
- A valid identifier belonging to another user, to confirm authorisation rather than obscurity protects the object.
Generation runs in your browser using the platform cryptographic random source, so nothing is requested from a server.
Frequently asked questions
What is the difference between a UUID and a GUID?
None technically. GUID is Microsoft’s name for the same 128-bit identifier. The practical difference is formatting: Microsoft tooling often uses uppercase and sometimes braces, so normalise case before comparing values across systems.
Can two UUIDs collide?
In theory yes, in practice no. Version 4 uses 122 random bits, and the number of identifiers needed before a collision becomes likely is far beyond anything an application will generate. Duplicates in a real system are almost always a bug in the code that reuses one, not a collision.
Are UUIDs secure enough to use as secret tokens?
A version 4 UUID from a cryptographic random source is unguessable, but unguessable is not the same as access controlled. Anything reachable only because the identifier is hard to guess is a security-through-obscurity design, and an object reachable with a valid identifier belonging to another user is a defect.
Should I use a UUID as a database primary key?
It is reasonable, with a caveat. Random version 4 keys fragment the index and slow inserts on large tables because each write lands at a random position. Version 7 keeps the uniqueness and restores time ordering, which is the better choice for a new system.
Is the all-zero UUID valid?
It is a legal value called the nil UUID, and it is widely used to mean none or unset. Because of that convention it deserves an explicit test: systems often accept it where they should reject it, or display it to a user as though it were a real identifier.
Why do some UUIDs appear with braces or without hyphens?
Those are alternative textual representations of the same 128 bits. Some APIs accept all of them and some accept only the canonical hyphenated form, which makes the variants useful input-validation test cases.