UUID / ULID 생성기

Why unique IDs need to be generated, not assigned

When two systems create records independently — a phone offline, a server in another data center, a background job — neither can ask a central authority "what number comes next?" without a slow round trip and a single point of failure. The answer is to generate an identifier so large and so random that the chance of two systems ever producing the same one is effectively zero. That is what UUIDs, ULIDs, and Nano IDs do. This generator builds all of them locally using crypto.getRandomValues(), the browser's cryptographically secure random source, so the randomness is genuine and the values never leave your device.

The four formats, side by side

How each format is built

UUID v4 is almost entirely random: 122 of its 128 bits are filled from the secure random source, with six bits fixed to mark it as version 4, variant 1. The version digit is always 4 and the first character of the fourth group is always 8, 9, a, or b. UUID v7 replaces the leading bits with a 48-bit millisecond timestamp, then fills the rest with randomness. Because the timestamp comes first, sorting v7 values alphabetically also sorts them chronologically. ULID uses the same idea but encodes the 48-bit timestamp and 80 random bits in Crockford's base32 alphabet (it omits I, L, O, and U to avoid confusion with digits), yielding a compact, case-insensitive, sortable string. Nano ID drops timestamps entirely: it maps 21 random bytes onto a 64-character URL-safe alphabet, producing a short token ideal for links.

A worked example: choosing v4 versus v7 for a database key

Imagine you store a million orders, using the ID as the primary key in a B-tree index. With random UUID v4 keys, each new insert lands at a random spot in the index, scattering writes across the whole structure and hurting cache locality. Switch the format dropdown to UUID v7 and every new ID is slightly larger than the last, so inserts append to the end of the index — far friendlier to the database. You get the same global uniqueness, but with the insert performance of an auto-incrementing integer and the additional benefit that the creation time is recoverable from the ID itself.

Just how unlikely is a collision?

UUID v4 has 122 bits of randomness, which is roughly 5.3 × 10³⁶ possible values. To reach even a one-in-a-billion chance of any collision you would need to generate on the order of a billion UUIDs per second for around 85 years. For every practical application, treating a v4 UUID as unique is safe. The time-ordered formats share their randomness budget with a timestamp, so two IDs generated in the same millisecond rely on 74–80 random bits to stay distinct — still astronomically safe for normal request rates.

Practical use cases

• Database primary keys that can be created offline or merged from multiple sources without renumbering.
• Idempotency keys so a retried API request is not processed twice.
• Public URL tokens — Nano ID's short, URL-safe form is perfect for share links and short identifiers.
• Correlation IDs threaded through logs to trace one request across many services.
• Bulk seeding — set the count up to 100 to generate a batch of test fixtures at once.

Common mistakes

• Treating UUIDs as secrets. A v4 UUID is unpredictable, but v7 and ULID leak their creation time, and none should be used as a password or session token where secrecy matters.
• Exposing v7/ULID when timing is sensitive. Because the timestamp is embedded, anyone can read when a record was made — fine for keys, risky for anonymized data.
• Storing UUIDs as text when a binary column exists. Many databases offer a native 16-byte UUID type that is smaller and faster than a 36-character string.

Privacy

Generation is entirely client-side through the WebCrypto API. No identifier you create is sent to, logged by, or stored on any server — turn off your network and the Generate button still produces fresh, secure IDs.