Choose how many UUIDs to generate and select uppercase or lowercase output. Submit the form to generate the values on the server, then copy the list into your test data.
Choose how many values you need, pick upper or lower case, and submit the form to generate RFC 4122 version 4 UUIDs. Each result is a random 128-bit identifier in the canonical 8-4-4-4-12 hexadecimal form, ready to paste into fixtures, seed data or database rows.
Version 4 means the identifier was created from random bits rather than from a timestamp, a MAC address or a name hash, so nothing in the value reveals the machine that produced it or when it was created.
A UUID is 128 bits written as 32 hexadecimal digits in five hyphen-separated groups. In version 4, 122 of those bits are random, the four bits beginning the third group are fixed to 0100 so readers can tell it is a version 4 value, and the two most significant bits of the fourth group are fixed to 10 so the value follows the RFC variant. Those six fixed bits are why a genuine version 4 UUID is not simply 32 random hex characters.
Because 122 bits are random, there are about 5.3 times ten to the thirty-sixth possible values. The birthday bound, the point where a collision becomes likely, is around two to the sixty-first identifiers, so duplicates are not a practical concern for any system that generates identifiers at a human or even machine scale.
GUID is Microsoft's name for the same structure, and the two are interchangeable in practice; only the casing convention differs between ecosystems. ULID and UUID version 7 are different designs: both are 128 bits, but they begin with a millisecond timestamp so that sorting them alphabetically also sorts them by creation time, which keeps database index inserts sequential instead of scattering them across the tree.
The random layout of version 4 has a real cost in a database: keys arrive in no particular order, pages split constantly, and index size grows. If that matters, use a time-ordered identifier such as UUID version 7 or ULID for new tables, and keep version 4 for identifiers that are handed to clients or used in distributed systems where ordering is irrelevant.
Random UUIDs are unique, not secret. They are fine as opaque public identifiers, but treating one as a bearer capability, for example a password reset link or an unguessable share URL, only works if the value is also treated like a credential: transmitted over TLS, expiring, single use, and never logged in full.
UUIDs are case-insensitive hexadecimal, so 550E8400-E29B-41D4-A716-446655440000 and its lowercase form are the same value. Store them in one case, and watch out for systems that compare identifiers as case-sensitive strings, which turns a harmless formatting difference into a lookup failure.
Input: desired UUID count (1–100) and letter case (lowercase or uppercase); output: canonical UUID strings.
Generate primary keys for database records; create unique IDs for test fixtures; correlate requests across distributed services.
The requested UUID count and letter-case option are sent to VoriTools; its server generates canonical UUID strings without a source document upload.
Generated UUIDs are identifiers only; they are not suitable for authentication secrets, passwords, API keys, or session tokens.
For practical purposes, yes. The chance of a collision depends on how many values you generate and follows the birthday problem, but with 122 random bits you would need to generate billions of identifiers per second for decades before a duplicate became likely.
No. The hexadecimal digits may be written in either case and both forms identify the same value. Databases and languages differ in how they store and compare them, so pick one case for consistency and normalise on input.
Yes, with a caveat. Random version 4 keys make inserts non-sequential, which fragments B-tree indexes and slows writes on large tables. If you want the UUID format without that cost, use a time-ordered version such as UUID version 7 or a ULID, or store the UUID as binary rather than text.
It is safe to expose them as identifiers, because they cannot be guessed or enumerated. Just do not treat the UUID itself as an authorization token: check that the requester is allowed to see the object rather than assuming that knowing the identifier grants access.
Nothing structural. GUID is the name used by Microsoft tooling for the same 128-bit format; UUID is the name used by the RFC and the wider industry. Either name refers to the same kind of value.
Up to 100 per request on this page. Larger batches are better generated by your language runtime, where uuid4 or crypto.randomUUID can produce them without a round trip.