UUID Generator (v4 & v7)

Last reviewed on April 27, 2026.

Generates UUIDs in your browser. Two versions are supported: v4 (fully random) and v7 (time-ordered, useful as a database key). All randomness comes from the browser's crypto.getRandomValues — the same source the platform uses for cryptographic operations.

Version Count Uppercase Remove dashes

All values are random and locally generated.

What a UUID actually is

A UUID is a 128-bit identifier — sixteen bytes — written as 32 hexadecimal characters in five dash-separated groups: 8-4-4-4-12. Two of the characters carry version and variant bits (the 13th hex digit is the version; the 17th is the variant). The other 122 bits are payload, and what they contain depends on the version.

v4: random

Version 4 fills the 122 payload bits with cryptographic randomness. The collision probability is so small in practice that for any application generating fewer than a billion UUIDs per second for a hundred years, the chance of a collision is below the chance of a cosmic-ray bit-flip in your CPU. Use v4 when you need an opaque identifier and do not care about ordering.

v7: time-ordered

Version 7 reserves the high 48 bits for a Unix timestamp in milliseconds, then fills the rest with randomness. The result still looks like a random UUID to anyone who is not parsing it, but two UUIDs generated milliseconds apart sort lexicographically in time order. That property makes v7 a good database primary key in B-tree-indexed systems (Postgres, MySQL/InnoDB, SQL Server) — inserts append rather than scatter, which keeps index pages dense and write performance high.

v7 was standardized in RFC 9562 in 2024, replacing several earlier proposals (UUIDv6, ULID-style identifiers, KSUIDs). For any new system, v7 is now the right default if you want both UUID compatibility and time ordering.

v4 vs. v7 — a decision table

Use case	Pick	Why
Public API IDs	v4	Opaque — does not leak creation time.
Database primary keys	v7	Time order keeps the B-tree index dense.
Idempotency keys	v4	Time leak is harmless; randomness is everything.
Distributed log IDs	v7	Multiple nodes generate IDs that sort by time without coordination.
One-time tokens	v4 (or longer random bytes)	For security tokens, a UUID's 122 random bits are usable but not luxurious — see the password generator for higher-entropy alternatives.

Worked example: a v7 in action

Two v7 UUIDs generated 1.5 seconds apart might look like:

018f4a82-e0c2-7a3b-8f12-9a6f0e413dd1
018f4a82-e6a4-7c01-94b3-2bd1cf905f88

Notice the first 11 hex digits change only slightly (018f4a82-e0c2 → 018f4a82-e6a4). Sort the two strings lexicographically and you get the same order as their creation times. That is the whole trick.

Format options on this page

Uppercase. Some database tools and exports prefer uppercase hex. RFC 9562 specifies lowercase as the canonical form, but uppercase is accepted on parse.
Remove dashes. Produces a 32-character bare hex string. Useful as an embedded identifier or as a column value where the dashes would be wasted bytes. Same UUID; different rendering.

Common mistakes

Treating a UUID as a secret. A UUID is an identifier, not a token. v4's randomness makes it unguessable, but anyone who sees the URL gets the value. Use a separate authorization mechanism.
Generating UUIDs from Math.random(). Older libraries did this. Math.random() is not cryptographically random and can repeat across browser tabs. Always use crypto.getRandomValues or crypto.randomUUID().
Storing UUIDs as strings. Postgres has a native uuid column type that uses 16 bytes; storing as varchar(36) uses 36 bytes plus length overhead. The native type also indexes faster.
Mixing v4 and v7 in the same column. The string sorts will silently re-order: a v4 generated yesterday can sort anywhere relative to a v7 generated today. Pick one version per column.
Assuming hyphens are required. Some systems strip them on storage and restore on display; others store them literally. Test the round-trip before relying on either.

Where this fits with the other tools on the site

The fake prop-data generator emits UUID-shaped values labelled clearly as props for screen-recording use; this page is the right tool when you need real UUIDs. After generating, paste the JSON output through the JSON formatter to verify shape, or wrap the result in the box-drawing tool for a framed display in a CI log or dashboard mock.