UUID Generator (v4, Random, GUID)

How this page is maintained

• Steps and copy are checked against the current tool behavior.
• Browser limits, file-size constraints, or compatibility gaps are documented when relevant.
• Unless a page explicitly says otherwise, files and text stay in the browser during processing.

What a UUID Version 4 Looks Like

A UUID v4 is a 128-bit random identifier written as 32 hex digits in five hyphen-separated groups sized 8-4-4-4-12. Here is one:

f47ac10b-58cc-4372-a567-0e02b2c3d479

Only six bits are fixed. The first character of the third group is the version, and 4 means version 4. The first character of the fourth group is the variant, where 8, 9, a, and b all mean the same RFC 4122 layout. That leaves 122 random bits, so a repeat is not worth planning around: you would need to make about 2^61 of them before a 50 percent chance of one collision shows up.

Making a batch. This tool calls crypto.randomUUID in your browser, so no ID is sent to a server. Set the batch up to 50 and generate. If your schema stores IDs without hyphens, strip them and the same value reads:

f47ac10b58cc4372a5670e02b2c3d479

Uppercase output is there for APIs that want it, and you can copy one value or the whole batch at once.

Spotting a v4 string. A pattern such as ^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ matches one. The 4 in the third group and the 8, 9, a, or b in the fourth are what mark it as version 4 rather than another version.

Where the shape matters. A lowercase, hyphenated v4 string is what a PostgreSQL uuid column, most ORMs, and plain JSON APIs take with no conversion. The stripped 32-character hex form is the usual pick for tight storage or a filename. One thing a random ID will not do is sort by insert order, so if you need that, keep a separate time column. This comparison of UUID and auto-increment keys covers the trade-off. For hashing rather than naming, use the hash generator. For other test data, the random generator covers numbers, text, and picks.

How to Generate a Batch of UUIDs for Test Data

Set the count and press generate. The generator returns one UUID per line, up to 100 per run, and the copy button places the whole set on your clipboard at once, so a seed file or a fixture list takes one paste. Enter a value above 100 and it is clamped to 100 rather than rejected; enter zero or a negative number and it clamps to 1. Every identifier is built locally with the uuid package, which uses crypto.randomUUID where the browser provides it and falls back to crypto.getRandomValues for the random bytes, so no ID and no list of IDs is sent anywhere.

A generated value always has the same shape. Six of the 128 bits are fixed by the library before the string is written: one nibble is set to 4 to mark the version, and two bits are set to the RFC 4122 variant, which is why the fourth group always starts with 8, 9, a, or b. The remaining 122 bits are random, and that is the number that governs collisions.

How Many UUIDs Before a Repeat

The useful figure is not the size of one ID; it is how many you can store before a repeat becomes likely. Around 2.3 times 10 to the 18th power UUIDs would give a one in a billion chance of any collision at all. Put 1 billion identifiers in one table, a scale far past most test fixtures and most production tables, and the chance of a collision is about one in 9 trillion. A duplicate is not a scenario that needs defending against, but a uniqueness constraint in the schema is still worth having: it costs nothing and it turns a theoretical event into a loud error instead of silent data corruption.

Formatting and What to Store

Output is lowercase and hyphenated, the form that PostgreSQL uuid columns, most ORMs, and plain JSON APIs accept without conversion. Keep it in that form through your pipeline and only strip hyphens at the point of storage if a column is defined as text, because the 32-character form and the 36-character form are different strings as far as any comparison is concerned. One thing a version 4 ID will not do is sort by creation order, since the bits are random; if you need that property, keep a timestamp column beside it or look at version 7. This comparison of UUID and auto-increment keys covers the trade-off in more detail.

Key features

• One-click batches: Generate multiple UUIDs at once for seeding databases, API keys, or test fixtures.
• Standard UUID v4 format: Every ID is a 36-character lowercase UUID with the version and variant bits set per RFC 4122.
• Clipboard ready: Copy individual IDs or the entire batch instantly.

Frequently asked questions

Related guides

• UUID vs. Auto-Increment: Why Developers Choose Random IDs for Databases

  One of the first decisions you make when designing a database schema is: What should be the Primary Key? For decades, the default answer was Auto-Increment Integer (1, 2, 3...). It's simple, human-readable, and efficient. But in modern distributed systems, UUIDs (Universally Unique Identifiers) have become the gold standard. Why the shift? And when should you stick to the old ways? Let's dive…