UUID Generator
Generate UUID v4/v7, ULID and Nano ID — single or in bulk
About this tool
Generate universally unique identifiers in four flavors: UUID v4 (fully random, the everyday default), UUID v7 (time-ordered, the modern choice for database keys), ULID (time-ordered with a compact Crockford Base32 spelling), and Nano ID (short, URL-friendly). Generate one or up to a thousand at a time — one per line, ready to paste into a seed script.
Randomness comes from the Web Crypto API (crypto.getRandomValues), the cryptographically secure source, not Math.random. Generation is local, which means the IDs are not known to anyone else, not logged anywhere, and available offline.
If you are choosing an ID format for a new system: v7 and ULID sort by creation time, which keeps B-tree indexes happy and makes IDs roughly chronological in logs; v4 reveals nothing about when it was made, which is occasionally exactly what you want.
Frequently asked questions
- What is the difference between UUID v4 and v7?
- v4 is 122 random bits. v7 (RFC 9562) leads with a 48-bit unix-millisecond timestamp followed by random bits, so IDs generated later sort later. For database primary keys v7 typically improves insert locality and index size; v4 remains fine where ordering is irrelevant or timing must not leak.
- Can two generated UUIDs collide?
- With 122 random bits, the probability is so small it is not worth engineering around: you would need to generate billions of IDs per second for decades to reach even a remote chance. Collisions in practice come from bugs (reusing a seed, copying rows), not from randomness.
- Why choose ULID over UUID v7?
- They solve the same problem. ULID is 26 characters of case-insensitive Crockford Base32 — shorter and cleaner in URLs and logs — while v7 keeps the standard 36-character UUID shape that every database and library already accepts. Pick whichever your ecosystem handles more natively.
- Are these IDs safe to use as secrets or tokens?
- The randomness is cryptographically secure, but IDs are usually displayed, logged and indexed — treated as public. For session tokens or API keys, generate a dedicated secret with at least 128 random bits and treat it like a password instead.