UUID / GUID Generator Online
Generate RFC 4122-compliant UUID v4 (random) or UUID v1 (timestamp) identifiers instantly. Bulk-generate up to 100 at once and copy in one click. No signup, runs entirely in your browser.
⏱ 5 min read · Complete guide below
How the UUID Generator Works
- 1Choose a UUID version — v4 for fully random identifiers or v1 for timestamp-ordered identifiers.
- 2Set the count (1–100) to generate multiple UUIDs in one click — useful for test fixtures and database seeds.
- 3Optionally enable uppercase output for systems that require A–F in capitals instead of lowercase.
- 4Click Generate and use the Copy All button to copy all UUIDs to your clipboard as newline-separated values.
UUID Format: Understanding the Structure
A UUID is always 36 characters long in the canonical format xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx where M is the version digit (1 or 4) and N is the variant digit (8, 9, a, or b for RFC 4122). This gives 32 hex digits plus 4 hyphens. Version 4 UUIDs randomise every bit except M and N; version 1 UUIDs encode a 60-bit timestamp in the first three groups.
The UUID Versions Explained
There is more than one kind of UUID, and each version solves a different problem. Version 4 is the one most people mean by “a UUID”: every bit except the version and variant markers is random, which makes it trivial to generate anywhere with no coordination and impossible to guess or enumerate. Version 1 is built from a timestamp plus a node identifier, so v1 UUIDs generated over time are roughly ordered — handy for database indexing but at the cost of embedding the generation time and (historically) a machine's MAC address. More recent designs address v4's one real weakness for databases: UUID v7 and the closely related ULID put a millisecond timestamp in the high bits followed by randomness, giving you IDs that are both unguessable and time-sortable. This tool generates the two classic RFC 4122 versions, v4 and v1, which cover the overwhelming majority of everyday needs; reach for v7/ULID specifically when you want random-looking keys that still insert in order.
When to Use a UUID Instead of an Auto-Increment ID
The traditional database key is a sequential integer (1, 2, 3…), and it is compact and fast — but it has real drawbacks that UUIDs fix. Sequential IDs must be handed out by a single authority (the database), which makes them awkward in distributed systems, offline clients, or sharded databases where several nodes need to mint IDs independently; a UUID can be generated anywhere, by anyone, with no coordination and essentially no collision risk. Sequential IDs also leak information: exposing /users/1024 in a URL reveals how many users you have and invites attackers to enumerate /users/1025, /users/1026, and so on, whereas a random UUID reveals nothing and cannot be guessed. The trade-offs are size (16 bytes versus 4 or 8) and, for random v4, index fragmentation on insert — which is exactly why time-ordered variants exist. As a rule of thumb: use UUIDs when IDs are generated in multiple places or exposed publicly, and plain integers for a simple single-database app where neither concern applies.
Are UUIDs Really Unique?
The “universally unique” claim is probabilistic, not absolute, but the numbers make a collision a non-issue in practice. A v4 UUID has 122 random bits, which is about 5.3 × 10³⁶ possible values — a space so vast that you could generate a billion UUIDs per second for a century and the chance of ever seeing a duplicate would remain vanishingly small. To put it another way, the probability of a collision only becomes meaningful after generating on the order of a quintillion IDs. The one caveat is that this guarantee depends on good randomness: this tool uses the browser's cryptographically secure crypto.randomUUID(), so the bits are genuinely unpredictable. For production systems it is still wise to put a database UNIQUE constraint on the column as a safety net, but a random collision is not something you need to design around.
Tips for Using UUIDs in Development
Primary Keys in PostgreSQL
Use the uuid column type with a DEFAULT of gen_random_uuid() (PostgreSQL 13+) or this tool to pre-generate IDs. Consider uuid_generate_v1mc() for time-ordered keys.
JavaScript / Node.js
In modern browsers and Node 15+, crypto.randomUUID() generates a v4 UUID natively — no library needed. This tool uses the same API.
Avoid Sequential IDs in APIs
Exposing sequential integer IDs in URLs reveals record counts and enables enumeration attacks. UUID-based resource identifiers like /api/users/<uuid> prevent this.
Index Performance
Random UUIDs cause page splits in clustered B-tree indexes. If insert throughput matters, use UUID v1, ULIDs, or PostgreSQL's uuid_generate_v1mc() for time-ordered keys.
Storing in SQL
Use the native UUID type in PostgreSQL or MySQL 8+. Storing as CHAR(36) wastes 20 bytes per row; storing as binary BINARY(16) is more compact if UUID type is unavailable.
Testing and Fixtures
Bulk-generate UUIDs for test data seeds, mock API responses, or Postman environment variables. The newline-separated output pastes directly into SQL INSERT statements or JSON arrays.
Frequently Asked Questions
What is a UUID and what is it used for?
A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier), is a 128-bit number formatted as 32 hexadecimal digits in the pattern xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. UUIDs are used as primary keys in databases, to identify API resources, track sessions, name files uniquely, and anywhere a collision-resistant unique ID is needed across distributed systems.
What is the difference between UUID v1 and UUID v4?
UUID v1 is timestamp-based: it encodes the current date/time plus a random clock sequence and a node identifier (traditionally the MAC address). Two v1 UUIDs generated at different times are therefore ordered chronologically, which can be useful for database indexing. UUID v4 is completely random — each of the 122 significant bits is independently random, making it ideal for cases where the generation time must not be inferred from the ID.
Are these UUIDs truly unique? Can two be the same?
UUID v4 uses 122 random bits, giving 2¹²² ≈ 5.3 × 10³⁶ possible values. The probability of generating a duplicate in 1 billion UUIDs is roughly 6 × 10⁻¹³ — effectively zero for any practical application. UUID v1 adds a timestamp component, further reducing collision risk. For production systems generating millions of IDs you should still use a database-enforced UNIQUE constraint, but random collisions are not a realistic concern.
Is my data private? Are the UUIDs stored anywhere?
No data leaves your browser. The generation runs entirely in client-side JavaScript using the browser's built-in crypto.randomUUID() API for v4 and a timestamp algorithm for v1. No UUID you generate is transmitted to any server, logged, or stored. You can verify this by opening your browser's Network tab while generating.
What is the "bulk generate" feature for?
The count input lets you generate 1–100 UUIDs in a single click. This is useful for seeding databases, creating test fixtures, pre-generating IDs for batch imports, or populating lookup tables. The output is newline-separated so you can paste directly into a text file or script.
Should I use UUID v1 or v4 for my database primary key?
It depends on your database. UUID v4 is completely random, which causes index fragmentation in B-tree indexes (like PostgreSQL's btree or MySQL's InnoDB). UUID v1 — or better, a UUID v7 or ULID — preserves time-ordering, resulting in sequential inserts and far better index performance. For most web applications on modern databases, v4 is fine unless you're inserting millions of rows per day.
Can I use these UUIDs in my code?
Yes. These are standards-compliant RFC 4122 UUIDs. You can use them anywhere: as JavaScript string literals, Python strings, SQL VALUES clauses, JSON properties, or environment variable values. The uppercase option produces the same UUID with A–F in capitals, which some legacy systems require.