a64d0576-2ace-4796-98a0-9109877186a6
How to use
01
Set how many
Type a number between 1 and 1000 in the How many field. One is plenty for a test fixture, a thousand covers a seed script.
02
Click Generate
Each click produces a fresh batch through crypto.randomUUID(), so values are cryptographically random rather than derived from timestamps or MAC addresses.
03
Copy one or all
Every UUID row carries its own Copy button, and Copy all puts the whole batch on your clipboard separated by newlines, ready for a SQL insert.
Why UUID Generator
- Cryptographically strong UUID v4 from the Web Crypto API.
- Generate up to 1,000 at a time.
- Runs entirely in your browser.
Common questions
What version of UUID does this tool generate?
Version 4, the random kind. Out of 128 bits, six are fixed to mark the version and variant, and the remaining 122 come from a cryptographically secure random source.
Is a random guid generator the same thing as a UUID generator?
Functionally yes. GUID is Microsoft's historical name for the same 128-bit identifier format, so tools and databases treat the two labels interchangeably.
How likely is a collision between two generated UUIDs?
With 122 random bits there are about 5.3 undecillion possible values. You'd need to generate billions per second for decades before a duplicate becomes a realistic concern.
Can I use this as a bulk uuid generator for seeding data?
Yes, it produces up to 1,000 identifiers per click, and you can regenerate as many batches as you need. Copy all gives you a newline-separated list that pastes cleanly into scripts and spreadsheets.
Do the generated UUIDs ever leave my browser?
No. Generation runs locally through the Web Crypto API, so nothing is sent to a server, logged, or reused. Refreshing the page discards everything.
Why do all the UUIDs have a 4 in the same position?
That digit is the version marker. The first character of the third group is always 4 in a v4 identifier, and the first character of the fourth group is always 8, 9, a, or b, which encodes the variant.
Should UUID v4 values be primary keys in my database?
They work well when inserts come from many uncoordinated sources. The tradeoff is that random keys don't sort by creation time and can fragment indexes, so measure before committing to them on very hot tables.