Encoders & Utilities

UUID Generator

Генерує UUID v1, v4, v7, NIL або MAX батчами. Toggle для верхнього регістру, дужок чи без дефісів.

Version

When to use which version

  • v1 — time-based + MAC node. Good when ordering matters and you need debuggable insertion order. Leaks MAC/host info if real MAC is used; we generate a random multicast-bit node so no real hardware is exposed.
  • v4 — random. Default choice. Collision-resistant (2¹²² entropy), good for distributed systems where ordering doesn't matter. Bad for DB primary keys at scale (random order kills B-tree locality).
  • v7 — time-ordered (RFC 9562, 2024). 48-bit Unix-ms timestamp prefix → lexicographically sortable + index-friendly. Recommended for new DB primary keys. Use this if you can.
  • NIL00000000-0000-0000-0000-000000000000. Sentinel/placeholder value.
  • MAX — all-ones UUID (RFC 9562). Useful as "infinity" sentinel paired with NIL.

Про цей інструмент

UUID Generator emit-ить 128-bit Universally Unique Identifiers, сумісні з RFC 9562 (2024-оновлення оригінального RFC 4122). П'ять варіантів підтримується: v1 (time + MAC, передбачуваний у часі), v4 (випадковий — найпоширеніший), v7 (time-ordered random, сучасний default для БД-ключів), NIL (all-zero placeholder) і MAX (all-FF — корисно як «максимальна» межа в range-запитах). Генеруйте один або до 1000 одразу.

Уся випадковість приходить з crypto.getRandomValues() — того самого browser CSPRNG, який використовує TLS. UUIDs ніколи не повторюються на практиці: 122 біти випадковості v4 дають collision probability настільки малу, що генерація мільярда на секунду протягом 85 років має приблизно 50% шанс на одну колізію («birthday bound» для 122 біт). v7 скорочує randomness до 74 біт в обмін на time-ordering, що все одно collision-safe на будь-якому реалістичному масштабі.

Коли використовувати цей інструмент

  • Генерація sample БД-ID для тестів. Швидше за запуск ORM-генератора.
  • Вибір правильної версії. v7 сортується за часом, коли використовується як primary key — значно краще для B-tree-індексів, ніж v4. Використовуйте v4, лише коли активно хочете приховати порядок.
  • Seeding fixtures. 100 distinct UUIDs в один клік для тест-датасету.
  • Інспекція формату UUID. Валідуйте, що отриманий рядок справді валідний UUID, і дізнайтеся, яка це версія.

Про v7 vs v4

UUID v7 стандартизовано у 2024 саме щоб виправити anti-database-friendly randomness v4. v7 має timestamp (48 біт, millisecond resolution) у high-bits, тож свіжо-згенеровані UUIDs сортуються лексично за часом створення. Це тримає B-tree-індекс «щільним» (нові inserts кластеризуються на одному кінці) замість розкидування по сторінках. Для нових додатків v7 — новий default; v4 лишається корисним лише коли вам спеціально потрібна unguessability порядку.

Часті запитання

Яка різниця між v4 і v7 UUID?

v4 — 122 біти випадкових даних — порядок двох v4 UUIDs безглуздий. v7 вбудовує 48-bit Unix-millisecond timestamp у high-bits, тож v7 UUIDs, згенеровані пізніше, сортуються після раніше згенерованих. Для БД-primary-keys v7 драматично friendlier для B-tree-індексів; v4 розкидає writes по всьому індексу і викликає більше page splits.

Чи UUIDs справді унікальні?

Ефективно так. Для v4 з 122 бітами randomness треба було б згенерувати ~2.7 × 10^18 UUIDs, перш ніж мати 50% шанс на одну колізію. Світ генерує трильйони на рік, і колізії — не реальна проблема. v7 з 74 random-bits усе одно safe на рівні ~1.5 × 10^11 на мілісекунду. NIL UUID (00000000-...) — єдиний виняток, зарезервований.

Чому деякі UUIDs мають braces навколо?

Microsoft-конвенція — Windows COM і .NET часто показують GUIDs як {xxxxxxxx-xxxx-...}. Braces не частина значення, лише декоративні. Більшість інших екосистем (Linux, JSON-API, JavaScript) пишуть UUIDs без braces. Наш toggle дозволяє продукувати будь-який формат; перемикайте за потреби при interop з Windows-heavy стеками.

Чи можна використовувати їх як БД-primary-keys?

Так — UUIDs широко використовуються як PK. Для нових таблиць надавайте перевагу v7 (або ULID — родинному формату), щоб індекс лишався компактним. v4 технічно ОК, але викликає більше write amplification на B-tree-індексах через random scatter. PostgreSQL, MySQL 8+ і SQLite всі мають нативну або near-native UUID-підтримку; у MySQL pre-8 зберігайте як BINARY(16) для компактності.