UUID & ULID Generator

Quantity

Variants

UUID v4
Random 122-bit UUID v7
Unix ms + random UUID v1
Time-based (Gregorian) ULID
Crockford base32, 26 chars

Casing

Dashes (UUID)

Results

Click to copy individual ID

No IDs generated yet. Choose variants above and click Generate.

Direction

Input

Casing

Dashes (UUID)

Result

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify objects in computer systems. UUIDs were originally standardized in RFC 4122 (2005) and updated in RFC 9562 (2024) to add new versions (v6, v7, v8) and clarify the format. The canonical text representation is a 32-character hexadecimal string displayed in five groups separated by hyphens, totaling 36 characters (8-4-4-4-12).

For example, a UUID v4 looks like 550e8400-e29b-41d4-a716-446655440000. The 13th character (4 in this case) indicates the version, and the 17th character (a in this case) indicates the variant. UUIDs are designed so that anyone can generate one without coordinating with a central authority, and the probability of accidental collision is negligible — generating 1 billion UUIDs per second for 100 years only has a 50% chance of a single collision.

Common UUID Versions

UUID v1 — Time-based. Encodes a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) plus a clock sequence and the MAC address of the generating computer. Sortable by time but leaks the host's MAC.
UUID v4 — Random. 122 bits of randomness. The most widely used version; no embedded meaning, no leakage.
UUID v7 — Time-ordered (new in RFC 9562). 48-bit Unix millisecond timestamp followed by 74 random bits. Combines v1's sortability with v4's randomness. Recommended for new applications that need database-friendly identifiers.

What is a ULID?

ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier spec designed to be lexicographically sortable while remaining URL-safe and human-friendly. Each ULID is 26 characters long, encoded in Crockford base32 (alphabet: 0123456789ABCDEFGHJKMNPQRSTVWXYZ), and consists of two parts:

Timestamp (10 characters) — 48-bit Unix millisecond timestamp, encoded as 10 Crockford base32 characters. The first character of a ULID always encodes the highest bit of the timestamp, so ULIDs created in chronological order sort lexicographically.
Randomness (16 characters) — 80 bits of randomness from a cryptographically secure source.

A typical ULID looks like 01ARZ3NDEKTSV4RRFFQ69G5FAV. Crockford base32 deliberately excludes the letters I, L, O, and U to avoid confusion with digits, and ULIDs are case-insensitive (Crockford's spec treats upper and lower case as equivalent).

UUID vs ULID Comparison

Both are 128-bit identifiers, but they differ in encoding, sortability, and database friendliness. Choose UUID v4 or v7 if you need broad ecosystem compatibility; choose ULID if you want compact, sortable, URL-safe identifiers with no hyphens.

Property	UUID v4 / v7	ULID
Total size	128 bits	128 bits
String length	36 chars (with dashes)	26 chars
Encoding	Hex (base16)	Crockford base32
Casing	Lowercase (canonical)	Case-insensitive
Sortable	v4: No, v7: Yes	Yes (lexicographic = chronological)
DB index locality	v4: Poor (random B-tree writes), v7: Good	Good
URL-safe	Yes (with dashes)	Yes (no dashes)
Standardization	RFC 9562 (2024)	Community spec (2016)

UUID v4 vs UUID v7

Both are 128-bit values, but they differ in how the bits are allocated. The choice between them depends on whether you need sortability.

UUID v4 — Pure Random

122 bits of randomness, with 4 bits reserved for version (4) and variant. Pros: no information leakage, no embedded timestamp, well-known, supported everywhere. Cons: random distribution causes B-tree fragmentation in databases — new rows are inserted at random positions, hurting write performance on indexed primary keys.

UUID v7 — Time-Ordered

48-bit Unix ms timestamp at the start, 74 random bits after. Pros: lexicographically sortable, database-friendly (new rows append to the end of the index), preserves the time of creation. Cons: leaks creation time, requires RFC 9562 library support (added in 2024).

How to Use This UUID & ULID Generator

Generate tab

Choose a quantity — Click one of the preset buttons (1, 5, 10, 25, 50) or type a custom number (1–1000) in the input field.
Select variants — Tick the checkboxes for the ID types you want. UUID v4 and ULID are on by default. Multiple variants can be selected — the generator picks one at random per ID.
Adjust format — Choose uppercase or lowercase output, and whether UUIDs include or strip dashes. ULID is always 26 characters without dashes.
Click Generate — The results appear instantly. Each ID shows the variant label, the value, and (for UUID v1, v7, and ULID) the embedded timestamp decoded as a UTC date/time.
Copy — Use the per-ID copy button to copy a single value, or Copy All to copy every ID on a new line.

Convert tab

Choose direction — UUID → ULID or ULID → UUID.
Paste the value — UUIDs can be pasted with or without dashes. ULIDs must be 26 Crockford base32 characters.
Click Convert — The result appears instantly. This is a representation conversion: the underlying 128-bit value is preserved, only the encoding changes.

Privacy note: All generation runs in your browser using crypto.getRandomValues(). No data is sent to a server.

Frequently Asked Questions

What's the difference between UUID v4 and UUID v7?

UUID v4 is 122 random bits with no embedded meaning. UUID v7 (new in RFC 9562, 2024) uses the first 48 bits for a Unix millisecond timestamp, then 74 random bits. v7 is lexicographically sortable by time, which makes it far more efficient as a database primary key. v4 is still the right choice if you don't need sortability and want maximum ecosystem support.

Can UUIDs collide?

For UUID v4, the probability of collision is astronomically low: about 1 in 2¹²² per ID. Even generating 1 billion UUIDs per second for 100 years has only a 50% chance of producing a single collision. UUID v1 has a higher collision risk on the same host if the system clock goes backward, but production systems use the clock-sequence field to handle that. ULIDs have the same 128-bit space as UUIDs, with the same theoretical collision resistance.

What does "time-ordered" mean for UUID v7 and ULID?

The first 48 bits of UUID v7 and the first 10 characters of ULID encode a Unix millisecond timestamp. Two IDs generated in chronological order will compare as "less than" when sorted lexicographically (i.e. by string comparison). This is useful in databases: B-tree indexes stay compact because new rows are appended to the end, rather than scattered randomly across the index.

How is ULID different from UUID?

Both are 128-bit identifiers, but ULID is encoded as 26 Crockford base32 characters (no dashes, case-insensitive) and is always sortable because the first 48 bits are a timestamp. UUIDs are typically encoded as 36 hex characters (with dashes) and only v1, v6, and v7 are time-ordered. ULID is more compact and easier to read; UUID has broader ecosystem support and formal RFC standardization.

Can you convert between UUID and ULID?

Yes — at the byte level. Both are 128-bit values, so a UUID's 16 bytes can be re-encoded as a 26-character ULID (Crockford base32), and vice versa. The Convert tab on this page does exactly that. Important caveat: the conversion is purely representational. The bits don't change, so a UUID v1 timestamp will not magically become a ULID timestamp in the conventional sense — the ULID's first 48 bits will be whatever the first 48 bits of the UUID happen to be, and a ULID decoder will interpret them as a Unix ms timestamp whether that was the original intent or not.

Are these IDs cryptographically secure?

Yes. This tool uses the browser's crypto.getRandomValues() API, which is backed by the operating system's cryptographically secure pseudo-random number generator (CSPRNG) — /dev/urandom on Linux, BCryptGenRandom on Windows. The IDs are suitable for security-sensitive applications like session tokens and database primary keys.

Menu