A UUID (Universally Unique Identifier) is a 128-bit identifier that is globally unique across all systems and time. UUIDs allow distributed systems to generate unique IDs without any central coordination server, making them essential for modern software development. The standard format is a 32-character hexadecimal string in an 8-4-4-4-12 pattern (e.g., 550e8400-e29b-41d4-a716-446655440000). This tool supports three UUID versions -- v7, v4, and v1 -- along with formatting and bulk generation options.

How It Works

UUID (Universally Unique Identifier) is a 128-bit value that generates globally unique identifiers without a central server. A v4 UUID uses crypto.getRandomValues() to produce 122 bits of randomness, with 4 bits fixed as the version (0100) and 2 bits as the variant (10). The format is 8-4-4-4-12 hexadecimal characters (e.g., 550e8400-e29b-41d4-a716-446655440000). Collision probability is astronomically low, practically guaranteeing uniqueness.

Using the Generator

A fresh UUID appears in the display card the moment the page loads. Click the refresh button (the circular arrows) whenever you need another one, and the copy button to send the current value to your clipboard.
Choose a version from the Version dropdown: v7 for time-sortable IDs, v4 for pure randomness, or v1 for the classic timestamp-based layout. The display regenerates instantly when you switch.
Adjust the Format option to output lowercase or uppercase hex digits, and use the Separator option to include or strip the hyphens -- some systems store UUIDs as bare 32-character strings.
Need many at once? Enter a count between 1 and 100 next to Bulk Generate, press the Generate Bulk button, and copy the whole newline-separated list from the output box straight into a seed script, spreadsheet, or test fixture.

Common Places UUIDs Appear

The classic use is the database primary key. Auto-incrementing integers require one authority to hand out numbers, which becomes a bottleneck the moment your data is written by multiple services, regions, or offline clients. UUIDs remove that coordination entirely -- every writer mints its own keys and merges never collide. The trade-off is index behavior: fully random v4 values scatter inserts across a B-tree, which hurts write locality on large tables. That is precisely the problem v7 was designed to fix, since its leading timestamp bits keep newly created rows clustered together while the random tail preserves uniqueness.

Beyond databases, UUIDs show up wherever an identifier must be unguessable or globally unique: uploaded file names that must not overwrite each other, correlation IDs that follow a request across microservices and logs, idempotency keys for payment APIs, and device or installation IDs in mobile apps. Bulk generation earns its keep here when preparing test data -- a hundred ready-made IDs pasted into fixtures saves a tedious loop.

On collisions: a v4 UUID carries 122 random bits, giving about 5.3 undecillion (5.3 x 10^36) possible values. Thanks to the birthday paradox you would need to generate on the order of a quintillion UUIDs before the odds of a single duplicate become even remotely measurable. In practical engineering terms, treating them as unique is a safe assumption.

Questions People Ask

What actually differs between v1 and v4?

A v1 UUID is built from the current timestamp plus a node identifier, so its value reveals roughly when and where it was created, and values from one machine sort chronologically. A v4 UUID is 122 bits of cryptographic randomness with no embedded meaning at all. Pick v1 only when you specifically want that time ordering and do not mind leaking creation metadata; otherwise v4 (or v7) is the modern default.

Why is v7 the default here?

v7 combines the best of both older versions: a 48-bit Unix millisecond timestamp up front makes values sortable by creation time, while the remaining random bits keep them unpredictable. For database keys this means better index locality than v4 without v1's habit of exposing hardware details.

Could two generated UUIDs ever be identical?

It is not mathematically impossible, just so improbable that no real system plans for it. With 2^122 possible v4 values, duplicates remain vanishingly unlikely even at planetary generation rates sustained for years. Frameworks, databases, and cloud providers all rely on this assumption.

Are the generated values sent to or stored on a server?

No. Every UUID is produced locally in your browser using the Web Crypto API's crypto.getRandomValues(), and nothing is transmitted anywhere. Close the tab and no record of what you generated exists.

Is it safe to use a UUID as a secret token?

A v4 UUID is random enough that guessing one is infeasible, but UUIDs are identifiers by design, not credentials. For session tokens, password-reset links, or API keys, prefer a purpose-built random token with more entropy, and never use v1 for anything security-sensitive since it embeds time and node information.

Do the hyphens matter?

They are purely presentational, marking the 8-4-4-4-12 grouping. Removing them loses no information, and plenty of systems persist the bare 32-character form to save space. Just keep the hyphenated format when interacting with validators or libraries that expect the canonical RFC layout.

Uppercase or lowercase -- does it change the value?

No, hex digits mean the same thing in either case. RFC 4122 says generators should emit lowercase while parsers should accept both. Use lowercase unless you are matching the style of a legacy system that stores uppercase.

Quick Tip

Before seeding a database with generated IDs, confirm the column type matches your hyphen setting: a hyphenated UUID is 36 characters and will not fit in CHAR(32), while the bare form needs exactly 32. And decide on lowercase versus uppercase once, project-wide -- string comparisons in some databases are case-sensitive, and a mixed-case dataset is painful to clean up later.

UUID Generator

What is a UUID Generator?