UUID Generator

Generate one or many UUIDs: version 4 for random, version 7 for time-sortable IDs.

Version

Fully random. The default choice for most IDs.

Format

How to use

  1. Choose v4 random for a plain random ID, or v7 time-sortable if the ID also needs to sort roughly by when it was created.
  2. Set How many with the − and + buttons, the 1 / 10 / 100 shortcuts, or by typing any number from 1 to 100.
  3. Turn on UPPERCASE, Hyphens or braces to match the format your database or language expects.
  4. Press Copy next to any ID, or Copy all / Download .txt for the whole batch. ↻ New makes a fresh batch any time.

A unique ID with no server round trip

A UUID (Universally Unique Identifier) is a 128-bit value designed so that two different computers, generating IDs independently with no coordination between them, will not collide. No database lookup, no central counter, and no network call are required. That property is what makes UUIDs the default choice for database primary keys, request IDs, and anything else that needs an identifier before it has anywhere to register one.

Example

A freshly generated version 4 UUID (yours will be different every time, that is the point):

4ef105b6-d046-4be9-a7d0-826c275cfe24

A version 7 UUID carries its creation time in the first part, recoverable afterward:

01a09aa3-7a00-78c0-8530-780518a1c025

Options explained

Edge cases and common errors

Do the same thing in code

// JavaScript / browsers and Node 19+ (version 4 only, built in, no library needed)
crypto.randomUUID();

# Python 3.7+ (version 4; version 7 needs the separate uuid6 or uuid-utils package)
import uuid
str(uuid.uuid4())

Version 7 is new enough (finalized in RFC 9562, 2024) that few languages' standard libraries generate it natively yet. This tool implements the same bit layout by hand from the RFC rather than depending on a library.

UUID Generator FAQ

What’s the difference between version 4 and version 7?

Version 4 is entirely random (4ef105b6-d046-4be9-a7d0-826c275cfe24), so two IDs give no clue which was created first. Version 7 puts a millisecond timestamp in the first part of the UUID and randomizes the rest, so 01a09aa3-7a00-78c0-8530-780518a1c025 sorts correctly next to other version 7 UUIDs created before or after it. Reading that timestamp back out of the example above gives 2026-09-13T12:00:00.000Z, exactly the instant it was generated with.

Why would sorting by creation time matter for a database ID?

Databases that use the primary key to physically order rows on disk (most B-tree-indexed tables) suffer from index fragmentation when new keys insert at random positions, which is exactly what version 4 IDs do. Version 7 IDs insert in roughly increasing order, the same way an auto-incrementing integer would, while still being globally unique and unguessable in the random portion.

Are these IDs actually unpredictable, or just look random?

Both versions fill their non-timestamp, non-version, non-variant bits from the Web Crypto API’s cryptographically secure random number generator (crypto.getRandomValues), the same source browsers use for encryption keys. They do not use Math.random(), which is not designed to be unpredictable.

Is 00000000-0000-0000-0000-000000000000 a real UUID?

It's the "nil" UUID defined by the RFC: a reserved constant meaning "no ID" or "not set," not something this tool would ever generate. If you see 00000000-0000-0000-0000-000000000000 somewhere, it usually signals a missing or default value, not an actual generated identifier.

Runs entirely in your browser: this page is a static file with no server behind it, so nothing you paste can be uploaded. Last reviewed by Parthesh Gupta. Implements RFC 9562 (UUID).