Generator UUID
Buat UUID v1 (timestamp), v4 (acak), v7 (terurut waktu), atau UUID Nil. Buat satu atau sampai seratus sekaligus, pilih format output, atau tempel UUID di bawah untuk mengecek validitasnya.
Validasi UUID
Versi
UUID v1 menyimpan timestamp 60-bit plus ID node acak. Bisa diurutkan berdasar waktu pembuatan dan lebih tua dari v7, tapi membocorkan waktu pembuatan tiap nilai — jarang jadi pilihan bagus kecuali sistem yang kamu pakai memang secara spesifik butuh ini.
UUID v4 adalah 122 bit data acak. Versi paling umum dan tidak punya struktur yang bisa dideteksi — cocok untuk token, nama file, atau di mana pun kamu cuma butuh nilai unik.
UUID v7 diawali timestamp milidetik 48-bit, diikuti bit acak. Karena terurut waktu, ia terurut secara alami dan menjaga index database supaya tidak terfragmentasi — berguna sebagai primary key ketimbang integer auto-increment atau v4.
UUID Nil adalah konstanta 00000000-0000-0000-0000-000000000000 —
semua bit nol. Dipakai sebagai placeholder atau nilai sentinel yang berarti "tanpa ID", bukan
untuk membuat nilai unik.
Format output
550e8400-e29b-41d4-a716-446655440000550E8400-E29B-41D4-A716-446655440000550e8400e29b41d4a716446655440000{550e8400-e29b-41d4-a716-446655440000}urn:uuid:550e8400-e29b-41d4-a716-446655440000Sebaiknya pakai versi yang mana?
- Primary key database - v7. Terurut sesuai urutan penyisipan, menjaga index B-tree supaya tidak terfragmentasi.
- Token sesi atau API - v4. Tidak menyimpan timestamp yang bisa bocor, urutan tidak relevan.
- Slug URL publik atau nama file - v4. Tidak membocorkan kapan resource itu dibuat.
- ID event terdistribusi yang butuh urutan waktu kasar tanpa koordinasi pusat - v7.
- Interop dengan sistem lama yang mengharapkan ID berbasis MAC+timestamp - v1.
- Field placeholder / "tanpa ID" - UUID Nil.
Di mana v3 dan v5?
v3 (MD5) dan v5 (SHA-1) adalah versi berbasis namespace yang deterministik - namespace dan nama
input yang sama selalu menghasilkan UUID yang sama. Keduanya adalah operasi hashing, bukan
pembuatan acak, jadi tidak cocok untuk alat "klik untuk membuat": kamu perlu memberikan UUID
namespace dan string nama, dan hasilnya bisa direproduksi, bukan nilai baru. Kalau kamu butuh ini,
biasanya cukup satu panggilan uuid.uuid5(namespace, name) di sebagian besar
standard library, bukan sesuatu yang perlu dibuat di sini.
Pertanyaan
Apa itu UUID?
Nilai 128-bit yang dipakai untuk mengidentifikasi sesuatu tanpa otoritas pusat yang membagikan ID — di Windows disebut GUID. Bentuknya seperti 550e8400-e29b-41d4-a716-446655440000. Dua UUID v4 acak yang bertabrakan praktis mustahil terjadi: butuh miliaran UUID dibuat per detik selama puluhan tahun sebelum itu jadi mungkin.
Kenapa pakai v7 ketimbang v4?
Terutama untuk primary key database. UUID v7 menyimpan timestamp, jadi baris baru masuk dengan urutan yang relatif terurut — v4 yang acak menyebar ke seluruh index dan bikin lebih banyak page split. Untuk selain primary key (token sesi, API key, nama file), v4 sudah cukup.
Apa gunanya v1 atau UUID Nil?
v1 kebanyakan dipakai untuk kompatibilitas dengan sistem lama yang membuat UUID dari timestamp dan antarmuka jaringan — v7 melakukan tugas timestamp-terurut ini lebih baik tanpa membocorkan sebanyak itu. UUID Nil (semua nol) sebenarnya bukan "dibuat" — itu konstanta tetap yang dipakai beberapa API untuk mewakili ID yang kosong atau belum diisi.
Apakah UUID sama dengan GUID?
Ya. GUID cuma sebutan Microsoft untuk format 128-bit yang sama — keduanya bisa dipakai bergantian.
Apakah ini cukup aman dipakai sebagai token keamanan?
Ya — pembuatannya pakai crypto.randomUUID() dan crypto.getRandomValues(), sumber angka acak kriptografis dari browser, bukan Math.random().
Apakah ada data yang dikirim ke server?
Tidak. Pembuatan dan validasi sama-sama berjalan di JavaScript di browser kamu. Tidak ada permintaan jaringan sama sekali di sini.
Seberapa acak sebenarnya UUID v4?
122 bit - 6 bit sisanya dari total 128 bit dipakai tetap untuk menandai versi dan variant. Itu sekitar 5,3 × 1036 kemungkinan nilai. Brute-force atau menebak satu nilai bukan serangan yang realistis; risiko tabrakan yang biasa disebut (birthday paradox) itu beda soal - butuh miliaran UUID dibuat per detik selama bertahun-tahun sebelum tabrakan jadi mungkin, dan itu tidak ada hubungannya dengan menebak satu nilai spesifik.
Apakah UUID v7 terurut benar kalau diurutkan sebagai string biasa?
Ya. Timestamp milidetik 48-bit ada di 6 byte pertama, dicetak paling depan, jadi pengurutan string (lexicographic) sama hasilnya dengan pengurutan kronologis - tidak perlu parsing UUID buat mengurutkan daftar berdasarkan waktu pembuatan.
Bagaimana kalau dua UUID v7 dibuat di milidetik yang sama?
Prefix timestamp-nya sama, dan sisa ~74 bit acak yang menentukan urutannya - hasilnya efektif acak. Tetap unik, tapi dua ID dari milidetik yang sama tidak dijamin terurut persis sesuai urutan pembuatannya - hanya terjamin sampai granularitas milidetik.
Apakah ini sama dengan ULID?
Idenya mirip, encoding-nya beda. ULID juga 128 bit seperti UUID (timestamp 48-bit + 80 bit acak) tapi biasa ditulis sebagai 26 karakter Crockford-base32, bukan format hex bertanda hubung. UUID v7, yang distandarkan belakangan, membawa sifat sortable-timestamp yang sama ke dalam format dan RFC UUID yang sudah ada - itu sebabnya v7 sekarang banyak menggantikan ULID untuk desain baru.