UUID / ULID Generator
Generate UUIDs (v4 and v7) or ULIDs instantly. Click any value to copy.
Generated
-
Bulk Generate
The UUID and ULID generator produces fresh identifiers on demand in three formats: UUID v4 (pure random), UUID v7 (time-ordered with random suffix, RFC 9562), and ULID (Crockford Base32). Generate a single value or up to 100 at once for bulk inserts, test fixtures, or migration scripts. Every value uses cryptographically secure randomness from your browser, so the IDs are safe to use as production keys.
Which Format Should You Pick?
All three formats are 128-bit identifiers with the same uniqueness guarantees, but they store different information and have different characteristics:
- UUID v4 (Random): 122 bits of randomness, no embedded timestamp. The default choice for most applications because it requires no inputs and every standard library generates it. Not sortable by creation time.
- UUID v7 (Unix Epoch Time): 48-bit Unix millisecond timestamp followed by 74 bits of randomness. Defined in RFC 9562 (2024). Sorts by creation time when compared as strings, which improves database index locality for primary keys.
- ULID: the same idea as UUID v7 but encoded as 26 Crockford Base32 characters instead of 36 hex characters. Compact, case-insensitive, and visually distinct (no I, L, O, or U in the alphabet). Predates UUID v7 by about eight years.
Pick UUID v4 if you need maximum compatibility with libraries that do not yet know v7. Pick UUID v7 if you want time-ordered IDs in the standard UUID format. Pick ULID if you want a more compact, human-readable representation and your platform supports it. To decode an existing identifier and see which format it is in, use the UUID decoder or the ULID decoder.
How the Generator Works
Pick the format tab (UUID v4, UUID v7, or ULID) and the tool generates a fresh value immediately. Click Generate New to produce another one. The result section shows the value plus every common format variant: lowercase, uppercase, with braces ({...} notation common in C# and SQL Server), and without dashes (for compact storage). For ULIDs, the section also shows the UUID-compatible representation so you can store the value in a database UUID column.
- Single generation: click Generate New for one fresh ID. Useful when you need a quick test ID, a placeholder, or a single migration record.
- Bulk generation: enter a count (1-100) in the Bulk Generate section and click Generate to produce a batch in a single click. The result is one ID per line, ready to paste into a script, a test fixture, or a database insert. Click Copy All to put the whole batch on your clipboard.
- Embedded timestamp: for UUID v7 and ULID, the result shows the embedded creation moment as an ISO 8601 string. Two values generated in the same millisecond share the same timestamp but differ in their random suffix.
If you need to shift a timestamp before generating, the date add/subtract calculator handles date math. To check the gap between two generated IDs (and confirm they were really created in the order you expect), the date difference calculator works on Unix timestamps.
Why Randomness Matters
UUID v4 and the randomness portion of v7 and ULID all rely on cryptographically secure randomness to guarantee uniqueness. The generator uses your browser's built-in secure random API, which is the same one used by libraries like crypto.randomBytes in Node.js, secrets.token_hex in Python, and SecureRandom in Java. Each generated ID is genuinely unpredictable - reproducing a v4 UUID generated last week is computationally infeasible.
This is why every generated value is unique and safe to use as a database key or an externally-visible identifier. The 122 bits of randomness in UUID v4 give 2^122 possible values, which is enough that you would have to generate billions of IDs per second for centuries before a collision became statistically likely. For practical purposes, treat any generated ID as guaranteed unique.
When to Use Each Format in Practice
Real-world scenarios where each format fits best:
- Session tokens, CSRF tokens, password reset links: use UUID v4. Predictability is the only thing that matters here, and v4 gives maximum entropy with no leaked timestamp.
- Database primary keys for time-series data: use UUID v7 or ULID. The embedded timestamp improves insert locality (new rows cluster on disk) and makes pagination by ID match pagination by creation time.
- Public-facing record IDs: use UUID v4 or ULID. The embedded timestamp in v7/ULID is not a security concern, but it does reveal when a record was created - acceptable for most apps, not for systems where creation time is itself sensitive.
- Test fixtures and migrations: use bulk-generated v4 unless you need ordered IDs in the fixture. v7 or ULID makes fixtures easier to debug because the order they were created is visible from the IDs themselves.
- Sharded systems: use UUID v7 or ULID. Sortable IDs make cross-shard merging and time-window queries cleaner without needing a separate createdAt column.
Frequently Asked Questions
Practically yes. UUID v4 has 122 bits of randomness, giving 2 to the 122 possible values (about 5 followed by 36 zeros). To have a 1% chance of a single collision you would need to generate 2.71 quintillion IDs. For any realistic workload, treat every generated UUID as guaranteed unique without needing a uniqueness check.
Yes. The generator uses your browser's built-in secure random API (crypto.getRandomValues), which draws from the operating system's cryptographic random source. The output is suitable for security-sensitive uses like session tokens, CSRF tokens, and password reset links. Each value is genuinely unpredictable; an attacker cannot guess the next value from previously generated ones.
v4 is 122 bits of pure randomness with no embedded information. v7 (RFC 9562, 2024) puts a 48-bit Unix millisecond timestamp in the high bits and fills the remaining 74 bits with randomness. v7 is sortable by creation time when compared as strings, which improves database index performance for primary keys. v4 is best when predictability needs to be zero (security tokens); v7 is best when sortable IDs help (database keys).
Pick ULID when you want a more compact representation (26 characters vs 36) and your ecosystem already supports it. Pick UUID v7 when you want time-ordered IDs in the standard UUID format that every database, library, and tool recognizes. The two formats encode the same kind of data (millisecond timestamp + randomness), just with different display conventions.
No. Every click of Generate New produces a fresh value with fresh randomness. If you need a deterministic UUID derived from a string (for example, hashing a URL into a stable identifier), use UUID v3 or v5 instead. Those formats are name-based hashes that always return the same UUID for the same input. This generator only produces random or time-ordered values.
Up to 100 per click. The output is one ID per line in a single text area you can scroll, copy, or download. For larger batches, click Generate again to extend the list or copy the existing batch and start a new one. There is no hard upper limit on how many times you can repeat the bulk generation.
No. Generation runs entirely in your browser using local JavaScript. No value is ever transmitted to a server, logged, or stored anywhere outside your machine. This makes the generator safe to use for production keys and tokens that must remain private. Closing the browser tab clears all generated values from memory.
For UUID v7 and ULID, yes. The embedded timestamp reveals approximately when the value was generated (with millisecond resolution). For most use cases this is acceptable or even desirable. If creation time is sensitive (for example, anonymous submission timestamps), use UUID v4 instead, which has no embedded time and no way to infer when it was generated.
Yes. A ULID is 128 bits, exactly the same size as a UUID. The generator outputs a UUID-compatible representation for every generated ULID, formatted with the standard 8-4-4-4-12 dashed hex layout. The two are interchangeable at the bit level; you can store a ULID in a database UUID column and convert back and forth between the encodings without losing information.
Different systems expect UUIDs in different forms. PostgreSQL and most modern databases use the canonical dashed lowercase form. SQL Server and the .NET ecosystem often use the brace-wrapped form ({...}). Some legacy systems strip the dashes and store 32 hex characters. The generator shows all these variants at once so you can copy whichever your target system expects without converting manually.