Buat UUID
Privat — file Anda tidak pernah disimpan
Versi yang mana?
0 UUID Anda akan muncul di sini.
Cara kerjanya
Pilih versi
v4 untuk apa pun yang tidak boleh bisa ditebak. v7 untuk kunci database. Perbedaannya dijelaskan di halaman, bukan diasumsikan.
Tentukan jumlahnya
Satu, atau hingga sepuluh ribu sekaligus, dengan format opsional — huruf besar, kurung kurawal, tanpa tanda hubung, atau sebagai daftar berkutip yang siap dipakai di kode.
Salin hasilnya
Salin semua, atau unduh sebagai file teks.
Versi 4 atau versi 7, dan mengapa itu penting di database
UUID adalah 128 bit yang ditulis sebagai 32 digit heksadesimal dalam kelompok 8-4-4-4-12 yang sudah familier. Enam dari bit itu dipakai untuk menyatakan versi dan variannya, sehingga tersisa 122 bit acak di versi 4 — cukup banyak sehingga Anda bisa membuat satu miliar per detik selama satu abad dan tetap sangat kecil kemungkinannya melihat UUID yang sama dua kali. Itulah daya tarik utamanya: dua sistem yang tidak pernah berkomunikasi bisa sama-sama membuat identifier dan dengan aman berasumsi keduanya tidak akan pernah bertabrakan.
Agar hal itu berlaku, keacakannya harus sungguhan, dan di sini keacakan berasal dari sumber acak kriptografis, bukan dari generator angka acak biasa. Perbedaannya penting jika identifier dipakai sebagai token akses — link reset kata sandi, URL berbagi yang tidak bisa ditebak — karena generator yang bisa ditebak memungkinkan seseorang menghitung nilai berikutnya dari nilai-nilai sebelumnya. Dengan sumber kriptografis, tidak ada yang bisa ditebak.
Versi 7 ada karena versi 4 bekerja buruk sebagai primary key database. Versi 7 menaruh timestamp milidetik 48-bit di depan dan mengisi sisanya dengan data acak, sehingga UUID yang dibuat berurutan akan terurut sesuai waktu pembuatannya. Kedengarannya hanya kosmetik, padahal tidak: key acak menyebarkan setiap insert ke seluruh index, jadi setiap penulisan menyentuh halaman yang berbeda dan cache tidak lagi membantu, sementara key yang terurut waktu ditambahkan di satu ujung. Di tabel besar, perbedaan kecepatan insert-nya cukup signifikan, dan itulah alasan v7 distandarkan.
Kompromi ini nyata dan perlu dipertimbangkan. UUID versi 7 memberi tahu siapa pun yang melihatnya kira-kira kapan UUID itu dibuat, hingga milidetik, dan serangkaian UUID ini mengungkap seberapa cepat Anda membuat record. Untuk key internal, itu tidak masalah. Untuk identifier yang terlihat di URL — nomor pesanan, link dokumen, ID pengguna — itu kebocoran informasi kecil yang tidak dimiliki versi 4. Jika keduanya penting, gunakan v7 untuk primary key dan v4 untuk apa pun yang publik.
Jika Anda butuh hal lain
Buat UUID di tempat UUID itu dipakai. Setiap database dan bahasa pemrograman sudah menyediakannya — gen_random_uuid() di PostgreSQL, UUID() di MySQL, crypto.randomUUID() di JavaScript, uuid.uuid4() di Python — dan membuat sekumpulan UUID di browser lalu menempelkannya ke kode boleh saja untuk fixture atau pengujian, tetapi salah untuk apa pun yang dijalankan sungguhan.
Jika alasan memilih v7 adalah key yang bisa diurutkan, ada alternatif yang perlu diketahui. ULID mengodekan ide yang sama dalam 26 karakter yang lebih pendek dan tidak membedakan huruf besar kecil; identifier Snowflake muat dalam 64 bit, sehingga ukuran index-nya separuh dari UUID yang 128 bit. Dan di banyak database, integer auto-increment biasa masih lebih cepat dan lebih kecil daripada semuanya — UUID sepadan dengan biayanya jika identifier harus dibuat di beberapa tempat sekaligus, dan tidak sepadan jika tidak.
Pertanyaan yang sering diajukan
v4 atau v7 — mana yang saya butuhkan?
Jika untuk primary key database, v7. Jika harus mustahil ditebak — link reset kata sandi, kode undangan, identifier sesi — v4. Hanya itu keputusannya, dan kebanyakan orang tidak pernah tahu ada pilihan, karena hampir setiap generator hanya menyediakan v4.
Mengapa v4 buruk sebagai kunci database?
Karena v4 sepenuhnya acak, sedangkan index database itu terurut. Key acak yang baru mendarat di tempat acak di dalam index, jadi setiap insert menyentuh halaman yang berbeda, cache tidak lagi membantu, dan index menjadi terfragmentasi dan membengkak. Di tabel besar yang sibuk, ini perlambatan yang terukur dan makin parah seiring waktu. Ini bukan kekhawatiran teoretis — inilah alasan dokumentasi Postgres dan MySQL kini sama-sama membahasnya.
Apa itu UUID v7?
UUID yang 48 bit pertamanya adalah timestamp milidetik, diikuti data acak. UUID ini tetap unik secara global dan tetap 128 bit, tetapi karena waktunya ada di depan, UUID v7 terurut sesuai waktu pembuatannya. Key baru ditambahkan di akhir index alih-alih tersebar di dalamnya, persis seperti perilaku integer auto-increment — dengan keunikan UUID. UUID v7 distandarkan dalam RFC 9562 pada 2024 dan menjadi rekomendasi saat ini untuk tabel baru.
Apakah UUID v7 di sini benar-benar terurut?
Ya, termasuk dalam milidetik yang sama, dan justru bagian inilah yang paling sering salah diterapkan. Timestamp hanya punya resolusi milidetik, jadi membuat seribu ID dalam satu loop selesai dalam satu milidetik — dan jika bit rendahnya murni acak, seribu ID itu TIDAK terurut sesuai urutan pembuatannya. Generator ini memakai counter monoton yang dijelaskan dalam RFC 9562, sehingga satu batch selalu naik secara ketat, setiap saat. Buat seribu lalu urutkan; hasilnya kembali sesuai urutan pembuatannya.
Apakah UUID v7 aman ditampilkan secara publik?
Dengan satu catatan: UUID ini mengungkap kapan dibuat, hingga milidetik, memang sudah begitu rancangannya. Untuk kunci database, itu biasanya tidak berbahaya atau bahkan berguna. Tetapi jika waktu pembuatan itu sendiri sensitif, atau jika Anda membutuhkan identifier yang tidak bisa ditebak, gunakan v4 — v7 masih punya 74 bit acak, yang jumlahnya sangat banyak, tetapi timestamp-nya bisa dibaca dengan jelas oleh siapa pun yang memegang ID tersebut.
Apakah UUID ini cukup acak untuk aman?
Ya. Keacakannya berasal dari `crypto.getRandomValues`, generator browser yang aman secara kriptografis, tidak pernah dari `Math.random`. Perbedaan ini pernah menyebabkan kerentanan nyata: `Math.random` cepat tetapi bisa ditebak, dan token sesi yang dibangun dengannya pernah berhasil ditebak dalam praktik. UUID v4 punya 122 bit acak, cukup sehingga tabrakan bukan kekhawatiran yang nyata.
Apakah UUID dibuat di perangkat saya?
Ya, sepenuhnya, dan untuk identifier hal itu penting. UUID yang diambil dari server orang lain adalah UUID yang sudah dilihat orang lain — dan itu menggagalkan tujuannya jika Anda sedang membuat rahasia. UUID ini tidak pernah meninggalkan browser Anda. Setelah halaman dimuat, matikan Wi-Fi Anda dan alat ini tetap bekerja persis sama. Itulah cara paling sederhana untuk membuktikan sendiri klaim privasi ini, alih-alih sekadar memercayai kata-kata kami.
Apa itu nil UUID?
Semuanya nol: 00000000-0000-0000-0000-000000000000. Ini UUID yang valid dan dicadangkan, dipakai untuk berarti “tidak ada” atau “belum diatur” saat null tidak bisa dipakai. Kebalikannya, max UUID yang semuanya f, kadang dipakai sebagai penanda (sentinel) pengurutan. Keduanya disediakan di sini karena sesekali dibutuhkan dan merepotkan untuk diketik dengan benar.
Perlu diketahui: UUID versi 4 berasal dari sumber acak kriptografis browser, bukan Math.random, jadi aman dipakai sebagai identifier. Versi 7 menyematkan timestamp dalam milidetik, dan itulah yang membuatnya terurut dengan baik — sekaligus berarti UUID ini membocorkan kira-kira kapan dibuat. Jangan pakai v7 jika hal itu penting.
Pasang alat ini di situs Anda
Gratis untuk blog, halaman kelas, atau artikel bantuan apa pun. Tempel satu potong kode dan pengunjung Anda bisa langsung memakainya di halaman Anda.