UUID / ULID Generator
Create UUID v4, time-ordered UUID v7, ULID or short random IDs in bulk. Choose how many you need, strip the hyphens, change the case and copy the whole list
Generate unique identifiers on demand: UUID v4 (random), UUID v7 (time-ordered), ULID, and short random IDs. Pick the version, how many you need, and copy the list straight into your code, fixture data or database.
The choice matters: v4 is the safe default for a primary key, while v7 and ULID start with a timestamp, which keeps database indexes efficient because new rows are inserted near each other. Use short random IDs when you only need an opaque token rather than a standard identifier.
How to generate a UUID or ULID
Choose the identifier type
Set how many you need
Copy the list
FAQ
What is the difference between UUID v4 and v7?
Version 4 is purely random. Version 7 puts a millisecond timestamp first, so identifiers sort by creation time - better for database index locality, still globally unique.
What is a ULID?
A 26-character identifier using Crockford Base32: a 48-bit timestamp followed by 80 random bits. It is lexicographically sortable, which is useful in logs and file names.
Are these identifiers really unique?
They are generated from a cryptographically secure random source. The chance of a v4 collision is astronomically small, so for practical purposes yes.
Should I use them as database keys?
They are safe, but a random v4 key scatters inserts across the index. If insert performance matters, prefer v7 or ULID, which are time-ordered.
Can I generate many at once?
Yes, set the count and copy the whole list in one go - convenient for seeding test data.
Is anything sent to a server?
No, identifiers are generated in your browser.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Handling secrets safely
Developer tools process credentials more often than people realise, and the risk is not the algorithm but where the data goes. Hashing is one-way and is not encryption - MD5 and SHA-1 are broken for anything security-related, and even SHA-256 is the wrong tool for storing passwords, where bcrypt, scrypt or Argon2 exist precisely to be slow. Base64 is an encoding, not protection: anyone can decode it, so never treat it as obfuscation. A JWT can be read by anyone who holds it, which is why the payload must never contain secrets, and decoding a token does not verify its signature - verification requires the key. Everything on this site runs locally in your browser, which is the reason it can safely handle tokens and passwords at all.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.