Generators

UUID Generator

Generate various versions of UUID/GUID.

Generated UUIDs0 items
Click "Generate" to create UUIDs

What is a UUID Generator?

UUID (Universally Unique Identifier) is a 128-bit identifier used to uniquely identify information. UUIDs are designed to be globally unique without requiring a central authority.

UUID Versions

  • UUID v4 (Random): Generated using random numbers, most commonly used
  • UUID v1 (Time-based): Based on timestamp and MAC address
  • NanoID: Shorter, URL-friendly unique IDs

Use Cases

  • Database Primary Keys: Unique record identifiers
  • Session IDs: User session management
  • File Names: Unique file identifiers
  • API Tokens: Request tracking and authentication

Generates identifiers shaped like UUIDs — 32 hex digits in 8-4-4-4-12 form — in three modes: v4 random, a v1-style string whose first 12 hex digits are the current Unix millisecond timestamp, and a 21-character short ID. You pick the count, the casing, and whether hyphens stay.

What the 36 characters encode

A UUID is 128 bits written as 32 hex digits in five hyphen-separated groups of 8-4-4-4-12, 36 characters in total. Two nibbles are never random. The 13th hex digit is the version field, and this tool writes 4 in v4 mode and 1 in v1 mode. The 17th digit carries the variant: the generator forces its top two bits to 10, so it can only come out as 8, 9, a or b. Those six fixed bits leave 122 random bits in v4. RFC 9562, published in May 2024, obsoleted RFC 4122 while keeping this exact layout, so a string whose 13th digit is not a valid version, or whose 17th digit does not start with 10, is malformed no matter how plausible it looks. Strict validators test precisely these two positions first.

The v1 option is a hex timestamp, not RFC v1

In v1 mode the tool never reads a network card address. It calls Date.now(), converts the millisecond count to hex, left-pads that to 12 digits, then splits it 8-4: the first group holds the high 32 bits of the timestamp, the second the low 20. Because the most significant digits come first, sorting these strings lexicographically sorts them by creation time down to the millisecond. Genuine v1 stores 100-nanosecond intervals counted from 15 October 1582 as three fields in a different order, followed by a 14-bit clock sequence and a 48-bit node ID, historically the NIC MAC address. So this output leaks no hardware address, yet a standards-compliant v1 parser that reassembles the time will report a meaningless year. Treat it as a timestamp-prefixed opaque ID, and note that the assembled string is hard-trimmed to 36 characters as a last step.

Where the characters come from

All three modes draw characters with Math.random(). In V8 that generator is xorshift128+, returning doubles with 53 bits of precision; it repeats rarely and not predictably, but it is not a CSPRNG and enough outputs let you recover its internal state. For fixtures, cache keys and request trace IDs that is fine. For anything an attacker could guess — session IDs, password-reset links, invite codes — use crypto.randomUUID(), or fill 16 bytes from crypto.getRandomValues(), which browsers expose only in a secure context. The NanoID option instead takes 21 characters from 0-9A-Za-z: 62^21 is roughly 2^125, a nominal space on par with v4 in 21 characters rather than 36. Unlike the nanoid library alphabet it excludes - and _, so nothing needs URL escaping.

Worked example

One v1-style ID from a fixed millisecond

Input 
v1 mode, 1 ID, lowercase, hyphens kept, Date.now() = 1759234567890
Output 
01999a8d-2ed2-11f9-aadd-373963fcd6e9

The first 12 hex digits are the timestamp itself: 01999a8d2ed2 is 1759234567890 in hex, i.e. 2025-09-30T12:16:07.890Z, and the 1 after it is the version nibble. Everything past that comes from Math.random(), so only the 13-character prefix is reproducible; dropping the hyphens gives exactly 32 characters.

Limits and pitfalls

  • Every ID is drawn from Math.random(), which is not a CSPRNG — never use this output as a session token, password-reset link or API key; use crypto.randomUUID() for those.
  • The v1 mode has no 48-bit node, no 14-bit clock sequence and does not count 100-nanosecond intervals from 1582, so real v1 parsers will misread its timestamp field.
  • The count field defaults to 5, with min 1 and max 100; the max attribute is browser-side validation only and the generation loop applies no clamp.
  • NanoID output is 21 characters of 0-9A-Za-z, not a 128-bit UUID, so a database column typed as uuid (32 hex digits, optionally hyphenated) rejects it.
  • Uppercase and hyphen removal are string post-processing applied in that order, so the result is a 32-character N form; validators that match a 36-character pattern will not accept it.

Related tools

Five decisions the three modes cannot settle on their own

What you are doingThe generator on this pageSomething else
You need a few dozen throwaway IDs for a fixture or a seed fileFive are already in the list on load; change the count, press Generate, press Copy all and the newline-joined batch pastes straight into a YAML or CSV column. Nothing to install, nothing to run — this is the case the page is built for.Going past one batch, stop clicking: node -e "for(let i=0;i<500;i++)console.log(crypto.randomUUID())" emits 500 lines of the same 36-character shape, drawn from the OS CSPRNG instead of Math.random(). Keep the two sets interchangeable by leaving hyphen removal off here, so both sides hand over 36 characters.
The key has to come out of a plain string sort in creation orderv1 mode writes the current millisecond, in hex, into the first 12 digits, so sorting the strings sorts by time. The tie is the catch: two IDs minted inside the same millisecond share all 12 digits and the 1 that follows them, and everything past that is random, so their relative order carries no information.If the ordering is a schema requirement rather than a nicety, generate RFC 9562 v7 or ULID in the application: both keep a 48-bit millisecond prefix and fill the tail from the OS, so same-millisecond rows still tie-break predictably and a retried write does not depend on luck. Leave this page to keys whose order you never query.
The ID goes into an invite link and 21 characters is too longNanoID mode is fixed at 21 characters from 0-9A-Za-z — there is no size control anywhere on the page. That is 62^21, roughly 2^125. Cut the string yourself to 8 characters and about 2^47.6 survives, near 2.2×10^14: plenty for a shareable slug, too thin for anything that must stay unguessable.Take the nanoid package and pass the length as an argument, nanoid(10), instead of truncating the output; it also reads from crypto, which this short mode does not. Shorten only values whose worst case is a wasted click.
A uuid-typed column or a strict validator will consume the valuev4 is the mode to pick: the generator writes 4 at position 13 and forces position 17 into 8, 9, a or b, which is exactly the pair of checks a validator runs first. v1 mode reproduces the same silhouette, so it passes shape checks while placing a millisecond count where RFC v1 keeps 100-nanosecond intervals.When the other side actually parses version and timestamp, produce the real thing: uuidgen, Python's uuid.uuid1(), or v7 from the uuid package. Reserve this page for consumers that treat the string as opaque bytes.
The same input has to yield the same ID on every runTwo clicks on identical settings never repeat a value, because the list is rebuilt from fresh randomness each time. For a primary key that is the point; for a cache key, a dedupe token or a row that must survive a re-import, it silently produces duplicates.Use v5 — namespace plus name, SHA-1 — from the uuid package or uuid.uuid5() in Python. Deterministic by design, so the second import rebuilds the same 36 characters and an upsert stops multiplying rows.

One concrete scenario

Three hundred beta invite codes, and the uppercase checkbox

Issuing 300 invite codes for a closed beta: NanoID mode gives 21 characters each, so 300 codes are 6,300 characters of CSV body and sizing is not the problem. The uppercase checkbox is. It post-processes whatever the generator produced, and NanoID draws from 62 case-sensitive symbols, so forcing uppercase leaves 36 and cuts the space per code from 62^21 (about 2^125) to 36^21 (about 2^108.6). Still unguessable — the damage is compatibility: codes already handed out in mixed case no longer match a case-sensitive column in Postgres, and two codes differing only in case collapse into one string. Leave NanoID lowercase. Need 12 characters instead? Use the nanoid package, where length is an argument: 62^12 is about 2^71.

Frequently Asked Questions

How unique is a randomly generated UUID (v4)?
A v4 UUID carries 122 random bits. After generating on the order of 2^61 UUIDs, the chance of any collision is still around one in a billion — for practical purposes, generated IDs never collide.
Which UUID version should I use?
Use v4 for general-purpose IDs. If IDs serve as database primary keys or need time-ordered indexes, prefer v7: random v4 keys fragment B-tree indexes under heavy insert load.
Can I shorten a UUID for use in URLs?
Yes. Convert it to its 16 raw bytes and encode as Base64URL: 36 characters shrink to 22. Keep it URL-safe; decoding the Base64URL back to bytes restores the original UUID.

Content reviewed: