Generator UUID

UUID adalah ID 128 bit yang bisa dibuat tanpa bentrok, tanpa perlu pusat yang membagikan nomor

UUID (Universally Unique IDentifier) adalah pengenal sepanjang 128 bit, atau 16 byte. Biasanya ditulis sebagai 32 digit heksadesimal yang dipisah dengan pola 8-4-4-4-12, misalnya 0192f3a1-7c4e-7b21-9a3f-5c2d8e1f4a6b. Poin utamanya: meski tidak ada server yang mengelola nomor urut, nilai yang dibuat komputer-komputer berbeda secara terpisah praktis tidak akan bentrok. Di lingkungan Microsoft, hal yang sama disebut GUID.

Standar yang berlaku sekarang adalah RFC 9562 yang terbit pada Mei 2024 dan menggantikan RFC 4122 yang lama dipakai. Standar ini mencakup versi 1 sampai 8, tetapi untuk membuat UUID baru, biasanya hanya tiga versi yang dipilih. v4 hampir seluruhnya berisi angka acak, v7 menaruh waktu pembuatan di bagian depan sehingga bisa diurutkan, dan v5 berbasis nama sehingga nama yang sama selalu menghasilkan nilai yang sama. Alat ini bisa membuat ketiga versi tersebut, dan UUID apa pun yang ditempel akan dibaca versi serta waktunya.

Kapan UUID perlu dibuat sendiri

Database sudah bisa memberi nomor otomatis, jadi mengapa masih perlu membuat ID sendiri? Karena kadang nomor ditentukan di lebih dari satu tempat, atau ID dibutuhkan sebelum data disimpan.

• Data uji dan data contoh: Saat mengisi data palsu seperti 30 anggota atau 200 pesanan, Anda butuh banyak ID berbeda sekaligus. Tentukan jumlahnya, lalu tempel langsung sebagai array JSON atau daftar SQL.
• ID yang ditentukan sebelum disimpan: Aplikasi yang bisa dipakai offline atau layar yang menyimpan data dalam beberapa tahap harus menentukan ID sebelum dikirim ke server agar relasinya tetap terjaga. UUID tidak bentrok di mana pun dibuat, jadi Anda tidak perlu menunggu respons server.
• Menggabungkan data dari beberapa tempat: Jika tabel dari tiap cabang yang bernomor mulai dari 1 digabung, nomornya bertabrakan. Jika sejak awal memakai UUID, Anda tidak perlu memberi nomor ulang saat menggabungkan.
• Nama file dan objek: Jika nama file yang diunggah diganti dengan UUID, file bernama sama tidak akan saling menimpa.
• Pelacakan permintaan dan tugas: Saat satu permintaan melewati beberapa layanan, UUID yang sama di log menyatukan catatan yang tersebar menjadi satu alur.
• ID yang sama untuk objek yang sama: Jika objek sudah punya nama unik, seperti alamat atau kode produk, dan Anda ingin selalu memberinya UUID yang sama, pakai v5. Hasilnya sama di server mana pun, sehingga tidak perlu bertukar tabel ID.

Cara memakai

1. Pilih versi di bagian atas. Jika belum yakin, lihat perbandingan versi di bawah. Saat halaman pertama dibuka, 10 UUID v4 sudah dibuat.
2. Untuk v4 dan v7, isi jumlah (1 sampai 1.000) lalu tekan Buat ulang. Tombol 1, 10, 100, dan 1.000 langsung membuat UUID sebanyak itu. Untuk v5, pilih namespace dan tulis satu nama per baris, maka setiap baris menghasilkan satu UUID.
3. Di panel keluaran, pilih huruf (kecil atau kapital), bentuk (8-4-4-4-12, tanpa tanda hubung, kurung kurawal, urn:uuid:), dan keluaran (per baris, array JSON, daftar SQL). Nilainya tidak berubah, hanya penulisannya, dan yang disalin atau disimpan persis seperti yang tampil di daftar.
4. Tekan sebuah baris di daftar untuk membuka UUID itu pada diagram anatomi. Salin satu UUID dengan ikon salin di ujung baris atau tombol Salin di diagram, dan salin seluruh daftar dengan Salin semua atau Simpan file. Di daftar, pindah baris dengan tombol panah, lalu tekan Enter untuk menyalin baris itu.
5. Untuk mengecek UUID dari tempat lain, tempel ke kolom cek di atas diagram. Bentuk dengan kurung kurawal, urn:uuid:, tanda kutip, maupun 32 digit tanpa tanda hubung ikut terbaca, lalu ditampilkan versi dan variannya, serta waktu pembuatannya untuk v7, v1, dan v6.

v4, v7, atau v5: pilih yang mana

Alasan terbesar memilih v7 adalah pengurutan. RFC 9562 menjelaskan bahwa UUID yang berurutan waktu membuat nilai baru masuk berdekatan di dalam indeks, sehingga lokalitas indeks database membaik, dan selisihnya dengan memasukkan nilai acak bisa mencapai 10 kali lipat atau lebih. Di sisi lain, bagian keamanan pada dokumen yang sama meminta v4 dipakai jika UUID digunakan untuk keperluan keamanan. Sebab v7 memuat waktu pembuatan apa adanya, sehingga dari ID yang dipublikasikan saja orang bisa tahu kapan data itu dibuat.

v1 dan v6 juga memuat waktu, tetapi memasukkan alamat MAC perangkat sebagai nilai node, sehingga RFC 9562 menyarankan v7 daripada v1 atau v6 bila memungkinkan. v3 sama-sama berbasis nama seperti v5 tetapi memakai MD5, dan standar menyarankan v5 daripada v3 bila memungkinkan. Karena itu alat ini hanya membuat v4, v7, dan v5, sedangkan versi lain hanya dibaca di kolom cek.

Cara membaca satu UUID

Dari 36 karakter, hanya dua karakter yang posisinya sudah ditetapkan. Karakter ke-13 (huruf pertama kelompok ketiga, dihitung tanpa tanda hubung) adalah versi, dan dua bit pertama karakter ke-17 (huruf pertama kelompok keempat) adalah varian (variant). Pada format RFC 9562, bit varian adalah 10, sehingga karakter ke-17 pasti salah satu dari 8, 9, a, atau b. Sisa 122 bit diisi dengan hal yang berbeda untuk tiap versi.

Jika nilai contoh dari lampiran RFC 9562 ditempel ke kolom cek, tata letak yang sama terlihat di diagram anatomi.

Pada v7, 12 bit rand_a boleh diisi sesuai pilihan pembuatnya. Boleh sekadar angka acak, nomor urut yang naik 1 dalam milidetik yang sama, atau waktu yang dipecah lebih halus dari milidetik (RFC 9562 6.2). Alat ini memakai metode nomor urut (Method 1). Saat milidetik baru dimulai, nomor urut diawali dengan angka acak 11 bit, lalu naik 1 dalam milidetik yang sama, dan jika melewati 4.095, waktu dimajukan 1 milidetik. Karena itu, meski 1.000 UUID dibuat sekaligus, urutan di daftar sama dengan urutan saat diurutkan sebagai teks. 62 bit berikutnya selalu berupa angka acak baru.

Bentuk penulisan dan panjangnya

Mengubah penulisan tidak mengubah nilai 128 bitnya. Sesuaikan saja dengan bentuk yang diminta program penerima.

RFC 9562 menetapkan bahwa huruf heksadesimal boleh kapital, kecil, atau campuran, dan nilainya tetap sama. Namun jika program membandingkan UUID sebagai teks biasa, huruf kapital dan kecil dianggap nilai yang berbeda. Dalam satu sistem, samakan penulisannya.

Cara membuat di kode, database, dan terminal

• Browser dan Node.js: randomUUID di W3C Web Cryptography hanya membuat v4.
• Python 3.14 ke atas: Python 3.14 menambahkan uuid6, uuid7, dan uuid8, dan uuid7 menjaga urutan dalam milidetik yang sama dengan nomor urut 42 bit.
• PostgreSQL 18: Versi dan waktu dibaca dengan uuid_extract_version(), uuid_extract_timestamp().
• .NET 9 ke atas: NewGuid membuat v4.
• PowerShell: Membuat GUID acak.
• Terminal macOS: Keluarannya huruf kapital.
• Linux (util-linux): Jika ada sumber acak yang baik, bawaannya adalah metode acak. v5 dibuat dengan uuidgen --sha1 --namespace @dns --name www.example.com. Tergantung versi util-linux pada distribusi Anda, opsi -7 mungkin tidak ada.

Seberapa kecil peluang UUID bentrok

Pada v4, 122 bit berisi angka acak, sehingga jumlah nilai yang mungkin adalah 2¹²², sekitar 5,3 × 10³⁶. Peluang bahwa minimal satu pasang nilai yang sama muncul saat n nilai diambil dari sini diperkirakan dengan rumus masalah ulang tahun: 1 − e^{−n(n−1)/(2·2122)}.

Untuk mencapai peluang 50%, dibutuhkan 2,7 × 10¹⁸ UUID, jumlah yang butuh sekitar 86 tahun meski membuat 1 miliar per detik. Namun perhitungan ini mengasumsikan angka acaknya tersebar merata. Itulah alasan RFC 9562 meminta generator angka acak yang aman secara kriptografis, dan alat ini juga memakai crypto.getRandomValues() milik browser. Peluangnya tidak nol, jadi pada data produksi pasang batasan unik (unique constraint), dan siapkan penanganan untuk membuat nilai baru jika penyimpanan ditolak karena bentrok.

Pada v7, hanya nilai yang dibuat dalam milidetik yang sama yang mungkin bentrok. Di dalam satu generator, nomor urut yang naik mencegah bentrok, dan jika perangkat berbeda membuat nilai di milidetik yang sama, 62 bit acak di bagian belakang yang membedakannya.

Saat memakai v7 sebagai kunci database

• Simpan sebagai biner: RFC 9562 menyebut bahwa menyimpan UUID sebagai teks memakai 288 bit untuk nilai 128 bit, sehingga sebaiknya disimpan sebagai biner 128 bit bila memungkinkan. Jika ada tipe khusus seperti tipe uuid di PostgreSQL, pakailah itu.
• Urutkan menurut urutan byte: Pada v7, membandingkan byte dari depan, atau mengurutkan teks yang ditulis dengan huruf besar-kecil yang sama secara abjad, menghasilkan urutan pembuatan. Jika huruf kapital dan kecil dicampur, urutan teksnya rusak.
• Waktu hanya sebagai acuan: 48 bit awal v7 adalah jam perangkat yang membuatnya. RFC 9562 menyatakan tidak ada jaminan seberapa dekat waktu itu dengan waktu sebenarnya, dan dokumentasi PostgreSQL juga menyatakan waktu yang diambil belum tentu persis sama dengan waktu pembuatan. Jika Anda membutuhkan waktu pembuatan yang akurat, sediakan kolom tersendiri.
• Biarkan database yang membuat: RFC 9562 menyatakan bahwa jika seluruh data ada di satu database, UUID yang dibuat oleh database itu paling baik menjaga urutan. Pakai nilai dari alat ini untuk data uji atau ID yang harus ditentukan lebih dulu, dan untuk kunci yang terus bertambah selama produksi, lebih baik dibuat oleh fungsi database atau server.

Kesalahan yang sering terjadi

• Hanya memakai 8 karakter pertama: 8 karakter adalah 32 bit, sehingga dengan sekitar 77 ribu nilai saja, peluang munculnya nilai yang sama sudah 50%. Jika ingin memendekkan, jangan anggap potongan itu sama uniknya dengan UUID.
• Mengizinkan akses hanya karena tahu UUID-nya: Bagian keamanan RFC 9562 menyatakan bahwa UUID jangan dianggap sulit ditebak, dan jangan dipakai sebagai nilai yang memberi hak akses hanya karena seseorang memilikinya. Meskipun UUID ada di alamat yang dibagikan, pengecekan izin tetap harus dilakukan terpisah.
• ID publik yang dibuat dengan v7: Jika nomor anggota yang tampil di bilah alamat dibuat dengan v7, waktu pendaftarannya ikut terlihat. Untuk tempat yang waktunya tidak boleh terlihat, pakai v4.
• Selisih kecil pada nama v5: www.example.com dan www.example.com., spasi di awal atau akhir, serta perbedaan huruf besar-kecil semuanya dianggap nama yang berbeda, sehingga UUID-nya juga berbeda. RFC 9562 juga menjelaskan bahwa nama yang sama bisa punya beberapa penulisan, dan tiap penulisan menghasilkan UUID yang berbeda. Alat ini tidak memperbaiki nama, melainkan menghitungnya sebagai UTF-8 persis seperti yang ditulis.
• GUID dengan urutan byte yang berbeda: Guid.ToByteArray() di .NET membalik urutan byte pada tiga kelompok pertama. Sebagai teks hasilnya sama, tetapi saat dikirim sebagai byte, periksa urutannya.
• UUID berbasis nama sebagai primary key: RFC 9562 menyebut bahwa nilai yang tadinya dikira tidak akan berubah, seperti kode pos atau nomor izin, sering kali berubah kemudian, dan melarang UUID berbasis nama dipakai sebagai primary key.

Batasan dan hal yang perlu diperhatikan

• Sekali jalan, alat ini membuat sampai 1.000 UUID. Untuk v5, nama dihitung sampai 1.000 baris.
• Urutan v7 hanya berlanjut di dalam halaman ini. Urutannya terhadap nilai yang dibuat di tab atau perangkat lain pada milidetik yang sama tidak dijamin.
• Waktu v7 memakai jam perangkat ini. Jika jam perangkat salah, waktu di dalam UUID juga salah.
• v5 memakai SHA-1. RFC 9562 menetapkan bahwa UUID berbasis nama yang dibuat dengan hash lain seperti SHA-256 harus berupa v8, bukan v5, dan alat ini tidak membuat v8.
• v1, v3, v6, dan v8 hanya dibaca di kolom cek. Nilai node pada v1 dan v6 bisa jadi alamat MAC perangkat.
• UUID yang sudah dibuat hilang saat halaman dimuat ulang. Salin atau simpan sebagai file daftar yang Anda butuhkan.

Sumber

Tanggal acuan RFC 9562, W3C Web Cryptography, serta dokumentasi PostgreSQL 18, Python, .NET, PowerShell, dan util-linux dicek langsung pada naskah aslinya pada 22 Oktober 2026. Nilai v4, v7, dan v5 pada tabel contoh dicocokkan dengan modul uuid Python 3.14 untuk memastikan hasilnya sama dengan alat ini, dan tabel peluang dihitung dengan rumus di atas.

• 01IETF RFC 9562 — Universally Unique IDentifiers (UUIDs)Mei 2024, menggantikan RFC 4122. Bab 4 penulisan, 5.4 v4, 5.5 v5, 5.7 v7, 6.2 kenaikan monoton, 6.11 pengurutan, 6.13 DB, bab 8 keamanan, Lampiran A contoh
• 02W3C — Web Cryptography API, randomUUIDProsedur membuat UUID versi 4 sebagai teks huruf kecil
• 03PostgreSQL 18 — 9.14 UUID Functionsgen_random_uuid, uuidv4, uuidv7, uuid_extract_timestamp, uuid_extract_version
• 04Dokumentasi Python — uuiduuid6, uuid7, uuid8 ditambahkan di 3.14, nomor urut 42 bit pada uuid7
• 05Microsoft Learn — Guid.CreateVersion7Mulai .NET 9, versi 7 menurut RFC 9562
• 06Microsoft Learn — Guid.NewGuidUUID versi 4, entropi 122 bit
• 07Microsoft Learn — Guid.ToByteArrayMembalik urutan kelompok empat byte dan dua kelompok dua byte setelahnya
• 08Microsoft Learn — New-GuidPerintah PowerShell untuk membuat GUID acak
• 09uuidgen(1) — manual util-linuxBawaan metode acak, opsi -7 (--time-v7), --sha1 --namespace @dns

Pertanyaan yang sering diajukan

Alat yang sering dipakai bersama