UUID Generator
Generate v4 or v7 UUIDs, one or a thousand at a time, using your browser's own cryptographic random source. Copy them quoted, as a JSON array or as SQL values, so they paste straight into whatever you were writing.
Free · No signup · Runs entirely in your browser
Generated in your browser with crypto.getRandomValues, never on a server — so no identifier you use here has ever left the machine. This UUID generator does v7 as well as v4, which most do not.
122 random bits. The default choice for a public identifier.
Up to 1,000 at a time.
Paste straight into code.
Choosing a primary key type is one of the decisions a spec should have settled before the migration was written. Connect GitHub and Tekk turns what you want into specs your coding agent can actually execute against the real repo.
What the characters mean
A UUID is 128 bits, written as 32 hex characters in five groups:
550e8400-e29b-41d4-a716-446655440000
↑ ↑
| variant
version
Two positions are not random. The first character of the third group is the version, and the first character of the fourth group encodes the variant — it is always 8, 9, a or b for a standard UUID. Everything else is payload.
That is why a v4 has 122 random bits rather than 128: six of them are spoken for.
v4 and v7
| v4 | v7 | |
|---|---|---|
| Content | 122 random bits | 48-bit timestamp + 74 bits random |
| Sorts by creation | No | Yes |
| Leaks creation time | No | Yes |
| Good as a primary key | No | Yes |
| Good as a public ID | Yes | Only if the time is not sensitive |
Both are defined in RFC 9562, published May 2024, which replaced the older RFC 4122 and added v7 along with the Max UUID.
Why v7 exists
This is the practical reason to care, and it is about index behaviour rather than uniqueness.
A v4 primary key lands at a random point in the index on every insert. As the table grows past the point where the index fits in memory, each write touches a different page, and the database ends up reading a page from disk to write one row. Fragmentation follows, and the problem gets worse exactly as the table gets valuable.
A v7 begins with a timestamp, so consecutive inserts land next to each other. The hot pages stay hot and the index behaves like an auto-increment column — while still being generated client-side without a round trip, which is the reason to use a UUID in the first place.
The cost is that a v7 tells anyone holding it when the row was created, to the millisecond. For an internal key that is usually fine and occasionally useful. For an identifier in a URL, think about it first.
Ordering inside one millisecond
Generate a thousand v7s in the same millisecond and the timestamp cannot separate them. RFC 9562 §6.2 offers a fixed-length dedicated counter for this: the 12 bits immediately after the version count upward within the millisecond.
This tool does that, so a batch of 500 comes out already in order. Generators that fill those bits randomly produce values that are sorted only to millisecond resolution — usually fine, occasionally the source of a confusing test.
Storage
| Representation | Size |
|---|---|
Postgres uuid |
16 bytes |
char(36) text |
36 bytes |
char(32) without hyphens |
32 bytes |
MySQL binary(16) |
16 bytes |
On a table of any size the difference compounds through every index and every foreign key. Store the bytes; format at the edges.
How it works
- 1
Pick a version
v4 is 122 random bits and the right default for anything public. v7 puts a millisecond timestamp in the leading 48 bits so the values sort by creation time — the version you want for a database primary key. Nil and Max are the two reserved values from RFC 9562.
- 2
Choose how many and how they look
Up to a thousand at once. Uppercase and hyphen toggles cover the systems that want a bare 32-character string, and the output mode wraps the batch as quoted strings, a JSON array or SQL value tuples. A UUID generator that makes you reformat the output by hand has done half the job.
- 3
Copy or download
Copy the whole batch or save it as a text file. Nothing is generated on a server and nothing is transmitted — the values come from crypto.getRandomValues in your own tab, which is the only way to be certain an identifier you are about to trust is not also sitting in someone's log.
Frequently asked questions
- What is a UUID?
- A 128-bit identifier written as 32 hexadecimal characters in five hyphenated groups. The point is that it can be generated independently, anywhere, without coordinating with a central authority, and still be unique in practice.
- Is a UUID GUID generator the same thing?
- Yes. GUID is Microsoft's name for the same 128-bit identifier, and the two terms are used interchangeably across ecosystems, so a UUID GUID generator and a UUID generator are the same tool under two names. The only real difference you will meet is that Microsoft tooling often wraps the value in braces.
- What is the difference between UUID v4 and v7?
- v4 is entirely random. v7 puts a 48-bit millisecond timestamp first and fills the rest with randomness, so values generated later sort after values generated earlier. A v4 uuid generator gives you unpredictability; v7 gives you ordering, and ordering is what a database index cares about.
- Which UUID version should I use?
- v7 for primary keys and anything you will sort or paginate by. v4 for identifiers exposed publicly, where a creation time embedded in the value would leak more than you want. A v4 uuid generator is the safer default for anything user-facing; if it is going in a database and you are not sure, use v7.
- Why is v4 bad for database primary keys?
- Because each value lands in a random position in the index. Inserts scatter across the whole B-tree instead of appending at the end, which fragments pages and pushes the working set out of memory as the table grows. v7 values are near-sequential, so inserts stay local and the index behaves like an auto-increment column.
- Are these UUIDs really random?
- They come from crypto.getRandomValues, the browser's cryptographically secure random source — not Math.random, which is predictable and unsuitable for identifiers. This UUID generator runs entirely client-side, so the values are generated by your machine and never transmitted.
- What are the odds of a collision?
- For v4, negligible at any scale you will meet. There are 2^122 possible values, and you would need to generate around 2.7 × 10^18 of them before a 50% chance of one collision. Practical systems fail for every other reason long before this becomes the concern.
- Can I use these in production?
- Yes for seed data, fixtures and one-off needs. For values your application generates at runtime, call your platform's own function — crypto.randomUUID() in browsers and Node, uuid_generate_v4() in Postgres, uuid.New() in Go. A UUID generator is for the moments when you need a value by hand, not a dependency in your code path.
- What is the nil UUID for?
- It is all zeros, and it means "no UUID" — a defined placeholder rather than null. RFC 9562 also defines a Max UUID of all ones as the other end of the range. Neither carries a version, which is why both are useful as sentinels precisely because they can never be generated by accident.
- Should I store UUIDs as text or binary?
- Binary where the database supports it. Postgres has a native uuid type at 16 bytes; storing the same value as a 36-character string costs more than twice that plus the comparison overhead on every index lookup. MySQL has no native type, so BINARY(16) with conversion at the edges is the usual answer.
- Why are some UUIDs uppercase?
- RFC 9562 says to output lowercase but accept either on input. Uppercase is a Microsoft convention that comes with GUIDs. They are the same value, and comparisons should be case-insensitive — the uppercase toggle above exists because some systems still insist.
- Do you log the UUIDs I generate?
- No. They are generated in your browser and never sent anywhere. There is no server call to log, no account, and no analytics on the values. Disconnect from the internet and the page still works — which is the property that matters if you are about to use one as a secret.
- Why is this free, and what is Tekk?
- Tekk is a spec-driven development platform for people building software with AI coding agents. This tool costs us nothing to run, and the developers seeding a table are the people we build for. No signup, no run limit, no upsell inside the tool.
Want a real spec for what you’re building?
Drop a sentence. Tekk grounds it in your actual code and turns it into an executable plan.
Free to try · Connect GitHub during signup