UUID generator
Processed in your browser · nothing is uploaded
Generates version 4 UUIDs from your browser’s cryptographic random source: 122 random bits each, enough that a collision is not something you will observe. The same box makes ULIDs of 26 characters with the timestamp first, Nano IDs of 21 URL-safe characters and locally-administered MAC addresses, and reports the version and variant of a UUID you paste in.
How to use the uuid generator
The three formats solve different problems and are worth telling apart. A v4 UUID is random, universally understood, and 36 characters. A ULID carries a 48-bit millisecond timestamp in front of 80 random bits, so a list of them sorts chronologically, which matters for database keys, because random UUIDs scatter inserts across a B-tree index and hurt write throughput on a busy table. Its alphabet is Crockford base32 with I, L, O and U removed, the first three to avoid confusion with digits and the last to avoid accidental words. A Nano ID is shorter, 21 characters by default and about 126 bits, because its 64-character alphabet carries six bits per character where hex carries four. Pick ULID for primary keys, Nano ID for anything appearing in a URL, and UUID when something else already expects one.
Validating is the fourth thing this does and it answers a narrower question than people expect. A UUID’s version lives in the first digit of the third group and its variant in the first digit of the fourth, so the format alone tells you which kind you are holding, and that a v1 encodes both the creation time and the MAC address of the machine that made it, which is a genuine information leak if those identifiers are public. What validation cannot tell you is whether the identifier was ever issued; the format being right says nothing about your own system having seen it.
If you are choosing today and nothing constrains you, UUID v7 is worth knowing about: standardised in RFC 9562, time-ordered like a ULID, and a better default than v4 for anything that becomes a database key.
A MAC address is the odd one out here, because it is the one identifier with structure in it rather than 48 opaque bits. The lowest bit of the first byte marks multicast and the next marks a locally-administered address, and the drawn ones set the second and clear the first: unicast, and from the space no manufacturer is ever allocated out of, so an invented address cannot collide with real hardware. That also means there is no OUI to look up, which is why a network scanner reports no vendor for one and is right to. It is the same trick phones use when they randomise their address per network, after a decade of shops and airports tracking devices by a fixed one.
What people use it for
- Seeding test data with identifiers that will not collide
- Choosing a sortable key for a busy table
- Making a short identifier for a share link
- Deciding between UUID, ULID and Nano ID before a schema is written
- Checking the version and variant of a UUID from a log
- Drawing MAC addresses for test data that cannot collide with real hardware
Questions
122 random bits. You would need to generate billions per second for decades before a collision was likely.
A ULID or a UUID v7 is usually better. Random UUIDs scatter inserts across the index; a time-ordered identifier keeps them sequential.
26 characters: 48 bits of timestamp and 80 of randomness, written in Crockford base32. That alphabet leaves out I, L, O and U, the first three to avoid confusion with digits and the last to avoid accidental words.
Yes. The first ten characters are the millisecond timestamp, which is also what makes a list of them sort chronologically.
A shorter random identifier: 21 URL-safe characters by default, carrying about 126 bits, slightly more than a v4 UUID, because its 64-character alphabet holds six bits per character where hex holds four. It is not sortable, having no timestamp in it, so a ULID or a UUID v7 is what you want where chronological order matters.
ULID for primary keys, Nano ID for anything that appears in a URL, UUID when something else already expects the format.
Yes. The validate option reads the format and reports the version, which lives in the first digit of the third group, and the variant, which is the first digit of the fourth. What it cannot tell you is whether the identifier was ever issued: only your own system knows that.
Yes. It encodes the creation timestamp and the MAC address of the generating machine, which is a real leak wherever those identifiers end up public.
Yes. Choose MAC address, set how many, and pick the notation: colon, hyphen or bare hex. They are unicast and locally administered, so they cannot collide with a real manufacturer’s allocation.
Up to fifty in a draw, in any of the four formats. Ten is the default.
A locally-administered address carries no OUI, so there is no manufacturer to look it up against. That is the point of the bit rather than a fault in the address, and it is the same trick a phone uses when it randomises its address per network, after a decade of shops and airports following devices by a fixed one.
Colon, hyphen and bare hex are in the Format list here. Cisco’s dotted quads are not drawn; the MAC address formatter converts an address you already have into that form.
A time-ordered version standardised in RFC 9562. It sorts chronologically, like a ULID, and is preferable to v4 for database keys.
No. UUIDs are case-insensitive, though lowercase is conventional.
No. They come from crypto.getRandomValues in your browser and are never transmitted.