UUID, ULID and NanoID generator
Generate UUID v4, UUID v7, ULID or NanoID identifiers in bulk, or paste one in below to find out what it is. Everything happens in this page — nothing you generate or paste is ever sent anywhere, and this tool makes no network requests after it loads.
About this tool
Generate turns out a batch of random identifiers of the type you pick — a UUID v4 or v7, a ULID, or a NanoID — one per line, ready to paste into a seed script, a test fixture, or anywhere else you need a run of unique IDs. Inspect does the reverse: paste any one of these in and it identifies which kind it is, decodes its version and variant (UUID), or its embedded timestamp (UUID v7 and ULID).
UUID v1, v3, v5, v6 and v8 exist too, but need a MAC address, a namespace and name to hash, or an application-defined payload respectively — none of which fit a bulk "just generate me some IDs" tool, so only the two purely-random-or-time-ordered versions people actually reach for by default are offered here.
How it works
All four use crypto.getRandomValues for randomness — the same cryptographically secure source the real uuid and nanoid npm packages use, not Math.random. NanoID uses the reference implementation's own default alphabet and algorithm (a single byte masked with & 63 against a 64-character set) rather than a reimplementation, for the same reason Base64 on this site uses the browser's native atob/btoa: the correct version already exists, so there is no reason to risk a subtly wrong one. UUID v4 and v7 are built by generating random bytes and overwriting the version and variant bits per RFC 9562. ULID follows the canonical ULID spec (github.com/ulid/spec) exactly: a 48-bit millisecond timestamp and 80 bits of randomness, each Crockford base32-encoded.
Common questions
UUID v4 or UUID v7 — which one do I want?
v4 is pure randomness — nothing about it reveals when it was created, and that is sometimes exactly what you want. v7 embeds a millisecond timestamp in the first 48 bits, so IDs generated later always sort after ones generated earlier. That makes it a much better database primary key — insert order matches ID order, which keeps index pages sequential instead of scattering writes randomly across the whole table — at the cost of leaking creation time to anyone who can see the ID.
Why would I use a ULID instead of a UUID v7?
They solve the same problem — a sortable, unique ID — differently. A ULID is 26 characters instead of 36, case-insensitive, and uses no hyphens, which makes it more compact to store as text and easier to select by double-clicking. A UUID v7 fits any column or library already typed for a standard UUID. Neither is more "correct"; it is a question of what the rest of your stack already expects.
Can two different tools generate the same ID?
In theory, yes — collisions are a probability, not an impossibility, for any of these. In practice the odds are astronomically small: UUID v4 and NanoID's default length both carry over 120 bits of randomness, and ULID's 80 bits of randomness per millisecond means you would need to generate hundreds of thousands of them in the same millisecond before collision risk becomes meaningful.
Is anything about the generated IDs sent anywhere?
No. Everything happens in your browser, using the Web Crypto API already built into it. There is no fetch, no beacon and no logging, and this page carries no third-party scripts.
When inspecting an ID goes wrong
"Not a recognised format"
The text doesn't match a UUID's 8-4-4-4-12 hyphenated hex pattern or a ULID's 26-character Crockford base32 pattern, and contains characters outside the URL-safe set NanoID uses by default. Check for stray whitespace, a truncated copy, or quote marks copied along with the value.
"Contains a character that isn't a valid hex digit"
The text has a UUID's hyphen positions (8-4-4-4-12) but one of the other characters isn't 0–9 or a–f — almost always a single mistyped or corrupted character. Check it against the source.
"Looks like a NanoID or similar ID, but this can't be confirmed further"
Not an error — NanoID (and IDs like it) have no fixed length and no reserved bits to check, unlike UUID and ULID, so there is nothing further this tool can verify about it beyond "every character is in the expected set."
"This is a ULID, but the timestamp overflows 48 bits"
The largest valid ULID is 7ZZZZZZZZZZZZZZZZZZZZZZZZZ — anything sorting after that encodes a timestamp beyond the year 10889, which cannot be a real ULID. This almost always means the text isn't actually a ULID, despite matching the character pattern.
The same job at the command line
uuidgenUUID v4, built in on macOS and most Linux distributions.node -e "console.log(crypto.randomUUID())"UUID v4, any platform with Node.js 16.7+.npx ulidULID, any platform with Node.js — installs nothing permanently.npx nanoidNanoID, any platform with Node.js. Add--size 10to change the length.
More tools
See the whole toolbox — thirty-seven free tools planned, all running in your browser.