UUID Generator

Need an ID that no other row, device or service will ever reuse? This UUID generator creates a 128-bit universal unique identifier right in your browser, so you can mint one value or a whole batch without asking a central system for permission. Pick a UUID version, copy the output, and move on.

Generate UUID Values with the Online UUID Generator

A UUID is a number written as 32 hexadecimal digits in five groups. Because every developer and every machine can create one on its own, there is no central counter to query and no coordination between distributed systems. That single property is why a UUID shows up in software of every size, from a tiny app to a global event pipeline.

Bulk generation and output formats

Whether you need one value or a long list, the workflow is the same. The options below mirror what backend developers and QA testers ask for most often:

• Bulk generation: create a batch at once for database seeding or test data.
• Standard format with hyphens, a compact string with no dashes, or a value wrapped in braces.
• Uppercase or lowercase hexadecimal digits.
• One-click copy to the clipboard, or export the list as a JSON array.

How to use this tool

1. Choose how many values you need and which type to create.
2. Pick the layout and letter case you want.
3. Press generate, then copy a single value or the entire list.

Each run of this UUID generator tool is client-side, so nothing you create or paste ever leaves your device. Because it is a UUID generator online, it also works on mobile and desktop screens without any install, and a long list is ready in a fraction of a second.

UUID v4 Layout and the 128-Bit Structure

A UUID v4 keeps that size but fills almost every position with randomness. Exactly 122 bits are chosen by chance; six are reserved, four to mark the version digit and two for the variant. The pattern xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx puts the 4 at the start of the third group, and y is one of 8, 9, a or b. A real value looks like 8ed111fa-8f03-422c-b233-5b2516dd74de.

The layout comes from RFC 4122, and the newer RFC 9562 adds further types on top of it. Both documents describe the same 36-character text form, which is why a single validator can read every type. The same value can be written four ways:

Pick whichever style the receiving system expects. Parsers in most languages accept all four, but a strict schema or a legacy import script may accept only one.

Choosing Between UUID v7, UUID v1 and UUID v4

The real question is rarely what a UUID is; it is which type belongs in a given column. Two facts decide it: whether the values sort by creation time, and how many random bits they carry.

A UUID v7 is time-ordered: a timestamp comes first, which makes the value sortable. A UUID v1 also embeds a clock reading, plus a node field that once held a MAC address; a browser has no access to one, so a random node stands in for it. A nil value of all zeros simply means no value.

Never treat a clock-based value as a secret. Anyone who has seen one can narrow the search for its neighbours, so choose v4 wherever an unguessable value matters.

How a Generate Random UUID Tool Stays Unique

A trustworthy way to generate random UUID values must never call Math.random(). This page relies on the Web Crypto API, whose CSPRNG is the same cryptographically random source browsers use for TLS. Math.random is a predictable pseudo-random function, which is fine for animations but poor for security. The Web Crypto source supplies the entropy behind all 122 bits.

The collision probability formula

The UUIDs you generate here never repeat in a statistical sense, not an absolute one. With N = 2¹²² possible values (about 5.3 × 10³⁶) and n UUIDs generated, the birthday approximation gives the chance of any collision:

For small results this simplifies to \(p \approx \frac{n^{2}}{2N}\). The chance grows with the square of n, not linearly, so the numbers only turn worrying at enormous scale.

A worked example with 250 million IDs

Suppose you keep generating UUIDs in bulk until a platform holds n = 250,000,000 of them. Then n² = 6.25 × 10¹⁶, and dividing by 2N (about 1.063 × 10³⁷) gives p ≈ 5.88 × 10^-21, roughly one chance in 170 quintillion that any pair matches. Push the table to 4 trillion rows and the risk only reaches 1.5 × 10^-12. A one-in-a-billion risk needs about 103 trillion values. In practice, a bug in your own code is far likelier than a lucky duplicate, so a batch of v4 UUIDs from this tool is safe to rely on.

Generate UUID Values to Seed a Staging Table

Priya Nair is preparing a staging copy of an orders service and needs 1,200 UUIDs from the generator as fresh order IDs before Friday's load test. The schema, a PostgreSQL 15 table named orders_stage, still declares the ID column as varchar(36), and the test script expects lowercase hyphenated text.

She sets the quantity to 1,200, keeps the v4 type, leaves the standard layout and lowercase on, and presses generate. The batch appears instantly, and she exports it as a JSON array so the loader can read it without any reformatting. Before pasting, she spot-checks the third group of the first value: it starts with 4, which confirms the type.

Then she checks the odds. With n = 1,200 and 2¹²² possible values, n²/2N comes to about 1.35 × 10^-31, so a duplicate in the batch is not a realistic concern and the script needs no retry logic.

The storage line is what changes her plan. Her 1,200 text values occupy 43,200 bytes of raw data (1,200 × 36), while the same IDs in PostgreSQL's native 16-byte uuid type need only 19,200 bytes (1,200 × 16), a 55.6% reduction. Since production will hold millions of rows, she changes the staging column to uuid now, reruns the load, and records the finding in the migration ticket so the production schema matches before launch.

UUID as a Database Primary Key

An auto-increment integer is compact, but it needs a single writer to hand out the next number. A UUID lets any application, mobile client or offline device assign a database primary key before the row ever reaches the database. That is a big reason unique identifiers dominate in distributed designs.

Index fragmentation and page splits

The cost shows up in the index. A v4 value is fully random, so each insert lands at an arbitrary leaf of the B-tree, causing page splits and index fragmentation. Write performance drops on a very large table. A time-ordered value or a ULID avoids this because new entries append to the end, so choose one of those if the table will hold hundreds of millions of rows and the creation time is not sensitive.

Binary storage beats text

Keep the value in its native 16-byte layout instead of a text column. A VARCHAR(36) wastes 20 bytes per row compared with 16 bytes of binary storage, and every comparison is slower. The built-in options differ by engine:

• PostgreSQL: the native uuid type, with gen_random_uuid() for values created on the database side.
• MySQL: BINARY(16) together with UUID_TO_BIN().
• SQL Server: the UNIQUEIDENTIFIER type.
• SQLite: TEXT or a 16-byte BLOB, since there is no native type.

Where a UUID v4 Generator Earns Its Keep

Developers reach for a UUID v4 generator every day. Typical applications include API testing, scripts that seed a database with many distinct rows, and DevOps work such as container labels and configuration IDs. Unique file names stop two uploads from overwriting each other, and event IDs let a message be traced across a pipeline.

Unpredictable values also help defend against IDOR flaws, because a guessed neighbour simply does not exist. They suit session tokens, API keys and password-reset links as a baseline, although a dedicated format is stronger for a login token or a long-lived secret.

Most frameworks already ship helpers: Laravel has Str::uuid(), Django has UUIDField, and many ORMs map a UUID column automatically. They are free for commercial use, since a UUID is just a number nobody owns.

Checking a Generated Universal Unique Identifier Before You Use It

A UUID you generate or paste can be inspected too. Confirm that the value you copied has 32 hexadecimal digits, that the third group begins with the type digit, and that the first digit of the fourth group is 8, 9, a or b. That tells you whether a string copied from a log line is a v4 or a time-based type, and it is how an inspector recovers a creation time from a v7.

Validation catches the quiet mistakes that are hardest to debug later: a dropped hyphen, a stray character from a copy and paste, or a value whose fourth group starts with the wrong digit. Run suspect strings through a check before they reach a migration, a fixture file or a message queue, because one malformed value can fail an entire bulk import halfway through.

Tips for Using Generated Unique Identifiers in Production

A few habits keep the output of a bulk run healthy as a project grows. Pick the writing style once, hyphenated lowercase being the safest default for URLs and JSON payloads, and copy the full value from the list rather than a truncated prefix, so support staff can search for it later.

Store each generated UUID in a binary column from the start. Switching from text to binary after millions of rows exist means a long migration, and treating the string as opaque keeps your code from depending on meaning that only a time-based type carries.

Frequently Asked Questions

Which UUID version should I use?

Version 4 (fully random) is the safe default for most uses -- no information about when or where it was generated leaks from the value itself. Version 7 is increasingly preferred for database primary keys specifically, because its embedded timestamp makes UUIDs sort chronologically and insert more efficiently into B-tree indexes than fully random v4 values. Version 1 is mostly legacy at this point -- it also embeds a timestamp, but in an older, less index-friendly layout.

Does Version 1 leak my MAC address?

Not with this tool -- the original UUID v1 spec used your network card's real MAC address as the 'node' component, which is a genuine privacy leak. This generator follows RFC 4122's recommended alternative instead: a cryptographically random node ID with its multicast bit set, which is indistinguishable from a real MAC address to any consumer but reveals nothing about your actual hardware.

Are Version 7 UUIDs actually sortable?

Yes -- the first 48 bits are a millisecond-precision Unix timestamp, so UUIDs generated later always sort after ones generated earlier when compared as plain strings or bytes. This is the entire reason v7 exists: to get the database-indexing benefits of a sequential ID while keeping the collision-resistance and decentralized generation of a UUID.

Can two different UUIDs ever collide?

For version 4, the chance of any collision among the 122 random bits is astronomically small -- you'd need to generate billions of UUIDs per second for centuries before a collision became likely. Version 7's timestamp reduces the random portion, but it's still generous enough (74 random bits) to make collisions practically impossible for any realistic generation rate.

Is any of this sent to a server?

No. Every UUID is generated entirely in your browser using the Web Crypto API's cryptographically secure random number generator -- nothing is transmitted, logged, or stored.