Skip to content

UUID Generator & Decoder — v1, v4, v5, v7

Generator UUID gratis — buat UUID v1, v4, v5, v7 secara instan. Decode & validasi UUID apa pun. Batch hingga 50. Tanpa pendaftaran, 100% di browser.

Tanpa Pelacakan Berjalan di Browser Gratis
Semua UUID dihasilkan secara lokal di browser Anda. Tidak ada yang dikirim atau disimpan.
Ditinjau untuk kepatuhan RFC 9562 dan kebenaran struktural — Go Tools Engineering Team · Mar 22, 2026

Apa Itu UUID?

UUID (Universally Unique Identifier) adalah identifier unik global 128-bit yang distandarkan oleh RFC 9562 (IETF, Mei 2024), dirancang untuk menghasilkan ID yang bebas tabrakan di seluruh sistem terdistribusi tanpa koordinasi pusat. UUID adalah format identifier yang paling banyak diadopsi di perangkat lunak modern — digunakan di primary key database, pelacakan request API, manajemen sesi, dan arsitektur microservice.

UUID ditulis sebagai 32 digit heksadesimal dalam format kanonik 8-4-4-4-12, seperti `550e8400-e29b-41d4-a716-446655440000`. Spesifikasinya dikelola oleh IETF; RFC 9562 menggantikan RFC 4122 sebelumnya (2005) dan secara resmi memperkenalkan UUID versi 6, 7, dan 8.

Ada lima versi UUID yang banyak digunakan. Versi 1 (v1) meng-encode timestamp saat ini dan alamat MAC mesin pembuat, menjadikan setiap UUID unik baik dalam waktu maupun ruang. Versi 3 (v3) dan versi 5 (v5) bersifat deterministik — mereka meng-hash namespace dan nama menggunakan MD5 atau SHA-1, selalu menghasilkan UUID yang sama untuk input yang sama. Versi 4 (v4) yang paling umum: mengisi 122 bit dengan data acak yang aman secara kriptografis, memberikan lebih dari 5,3 × 10³⁶ kemungkinan nilai (RFC 9562, Section 5.4). Versi 7 (v7) adalah standar terbaru: sebagaimana RFC 9562 Section 5.7 menyatakan, "UUID version 7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source" — menggabungkan timestamp milidetik 48-bit dengan data acak untuk menghasilkan UUID yang unik dan secara alami dapat diurutkan berdasarkan waktu pembuatan.

UUID esensial dalam sistem terdistribusi, database, API, dan di mana pun identifier unik diperlukan tanpa koordinasi terpusat. Mereka menghilangkan risiko tabrakan ID di seluruh sistem independen, menjadikannya ideal untuk microservice, event sourcing, dan arsitektur multi-tenant.

Alat ini menghasilkan semua versi UUID sepenuhnya di browser Anda menggunakan Web Crypto API — tidak ada UUID yang dikirim ke server mana pun. Tidak seperti generator berbasis server, tidak ada unggahan, tidak ada logging, dan tidak ada penyimpanan data. Aman digunakan untuk primary key database produksi, identifier API, dan aplikasi sensitif keamanan. Anda juga dapat mendekode dan memvalidasi UUID yang sudah ada untuk memeriksa versi, varian, dan data tertanamnya.

UUID terkait erat dengan primitif developer lainnya. UUID v1 dan v7 menyematkan timestamp Unix secara langsung, UUID v3 dan v5 menggunakan hash MD5 dan SHA-1 sebagai fondasinya, dan string UUID sering ditransportasikan di dalam payload JSON yang paling baik diperiksa dengan JSON formatter. Untuk pengenalan mendalam tentang format UUID, versi, dan kasus penggunaan dunia nyata, baca panduan UUID lengkap kami. Jika Anda memilih antara UUID v4, v7, ULID, dan Snowflake ID untuk primary key database, lihat perbandingan pemilihan ID kami.

// Generate a UUID v4 using the Web Crypto API
const uuid = crypto.randomUUID();
console.log(uuid);
// → '550e8400-e29b-41d4-a716-446655440000'

// Manual v4 generation with crypto.getRandomValues()
function generateUUIDv4() {
  const bytes = new Uint8Array(16);
  crypto.getRandomValues(bytes);
  bytes[6] = (bytes[6] & 0x0f) | 0x40; // version 4
  bytes[8] = (bytes[8] & 0x3f) | 0x80; // variant 10
  const hex = Array.from(bytes, b => b.toString(16).padStart(2, '0')).join('');
  return `${hex.slice(0,8)}-${hex.slice(8,12)}-${hex.slice(12,16)}-${hex.slice(16,20)}-${hex.slice(20)}`;
}

Fitur Utama

Dukungan UUID v7 (RFC 9562)

Hasilkan format UUID v7 terbaru dengan timestamp Unix tertanam untuk identifier yang berurut waktu dan ramah database. Salah satu dari sedikit alat online yang mendukung standar RFC 9562.

UUID Decoder & Validator

Parse UUID apa pun untuk mengungkapkan versi, varian, timestamp (v1/v7), clock sequence, dan informasi node-nya. Validasi secara instan apakah string merupakan UUID yang diformat dengan benar.

Dukungan Multi-Versi

Hasilkan UUID dalam lima versi — v1 (berbasis waktu), v3 (MD5), v4 (acak), v5 (SHA-1), dan v7 (acak berurut waktu) — semua sesuai RFC 9562.

Pembuatan Batch

Hasilkan hingga 50 UUID unik sekaligus. Setiap UUID dibuat secara independen dengan keacakan kriptografis penuh atau encoding spesifik versi yang benar.

Berbagai Format Output

Output UUID dalam format standar huruf kecil, HURUF BESAR, tanpa tanda hubung, atau kurung kurawal {GUID} — sesuai format yang dibutuhkan sistem atau framework Anda.

Aman Secara Kriptografis

Menggunakan Web Crypto API (crypto.getRandomValues()) untuk pembangkitan angka acak sejati — standar yang sama yang digunakan browser modern dan alat keamanan.

100% Berbasis Browser

Semua UUID dihasilkan secara lokal di browser Anda. Tidak ada yang dikirim ke server mana pun — identifier yang dihasilkan tetap sepenuhnya privat.

Perbandingan Versi UUID

Pilih versi UUID yang tepat untuk kasus penggunaan Anda.

Versi Basis Dapat Diurutkan Privasi Terbaik Untuk
v1 Timestamp + alamat MAC Berdasarkan waktu pembuatan Mengekspos MAC & waktu Sistem lama yang memerlukan pengurutan berbasis waktu
v4 122 bit acak kriptografis Tidak Sepenuhnya anonim Tujuan umum — versi yang paling banyak digunakan
v5 Hash SHA-1 dari namespace + nama Tidak Deterministik, dapat direproduksi ID konsisten dari input yang diketahui (URL, DNS)
v7 Timestamp Unix (ms) + acak Berdasarkan waktu pembuatan Hanya mengekspos waktu pembuatan Database modern — dapat diurutkan, ramah indeks (RFC 9562)

UUID vs Format ID Lainnya

ULID

26 karakter, Crockford Base32

Dapat diurutkan secara leksikografis seperti UUID v7, tetapi menggunakan encoding Crockford Base32 (26 karakter vs 36). UUID v7 sekarang menjadi alternatif yang distandarkan IETF dengan dukungan tooling yang lebih luas.

nanoid

21 karakter, alfabet aman URL

Lebih pendek dan aman URL, ideal saat ukuran ringkas penting. Bukan standar formal — tidak memiliki tipe database bawaan dan library lintas platform yang dimiliki UUID.

CUID2

Panjang variabel, alfanumerik

Dirancang untuk penskalaan horizontal dengan ketahanan tabrakan. Adopsi kurang luas dibanding UUID; tanpa dukungan database bawaan. Pertimbangkan UUID v7 untuk ID berurut waktu yang terstandar.

Contoh Versi UUID

UUID v4 (Acak)

550e8400-e29b-41d4-a716-446655440000

Versi yang paling umum digunakan. 122 bit keacakan kriptografis menyediakan lebih dari 5,3 x 10^36 kemungkinan nilai — cocok untuk hampir semua kasus penggunaan di mana keunikan diperlukan tanpa koordinasi.

UUID v7 (Berurut Waktu)

01906b5e-4a3e-7234-8f56-b8c12d4e5678

Menggabungkan timestamp Unix 48-bit dalam milidetik dengan data acak. UUID diurutkan secara kronologis, menjadikannya ideal untuk primary key database di mana lokalitas indeks penting. Direkomendasikan untuk proyek baru dibanding v1 dan v4.

UUID v1 (Berbasis Waktu)

6ba7b810-9dad-11d1-80b4-00c04fd430c8

Meng-encode timestamp 60-bit dan alamat MAC 48-bit mesin pembuat. Menjamin keunikan dalam waktu dan ruang tetapi dapat membocorkan informasi identitas hardware. Digantikan oleh v6/v7 di RFC 9562.

UUID v5 (Berbasis Nama SHA-1)

886313e1-3b8a-5372-9b90-0c9aee199e5d

UUID deterministik yang dihasilkan dengan meng-hash namespace DNS dengan nama 'python.org' menggunakan SHA-1. Namespace dan nama yang sama selalu menghasilkan UUID yang sama, menjadikan v5 ideal untuk identifier yang dapat direproduksi.

Cara Menggunakan

  1. 1

    Pilih Versi UUID

    Pilih dari v1 (berbasis waktu), v3 (berbasis nama MD5), v4 (acak), v5 (berbasis nama SHA-1), atau v7 (acak berurut waktu). Setiap versi melayani tujuan berbeda — v4 paling umum untuk penggunaan umum.

  2. 2

    Konfigurasi Opsi

    Untuk v3 dan v5, pilih namespace (DNS, URL, OID, X.500, atau kustom) dan masukkan nama untuk di-hash. Atur jumlah dari 1 sampai 50 dan pilih format output: standar huruf kecil, HURUF BESAR, tanpa tanda hubung, atau kurung kurawal {GUID}.

  3. 3

    Generate UUID

    Klik tombol Generate. Setiap UUID dibuat menggunakan Web Crypto API (crypto.getRandomValues()) untuk keamanan kriptografis. Field spesifik versi seperti timestamp (v1/v7) dan hash (v3/v5) di-encode dengan benar.

  4. 4

    Salin dan Gunakan

    Klik tombol Salin di samping UUID mana pun untuk menyalinnya ke clipboard, atau gunakan Salin Semua untuk mengambil semua UUID yang dihasilkan sekaligus. Beralih ke tab Decode untuk menganalisis versi, varian, timestamp, dan informasi tertanam lainnya dari UUID yang sudah ada.

Kasus Penggunaan Umum

Primary Key Database
Gunakan UUID v4 atau v7 sebagai primary key unik tanpa koordinasi antar node database. UUID v7 sangat cocok karena properti berurut waktunya meningkatkan performa indeks B-tree.
Sistem Terdistribusi
Hasilkan identifier unik secara independen di seluruh microservice, antrian pesan, dan sistem event sourcing. UUID menghilangkan kebutuhan layanan pembuatan ID terpusat.
Pengembangan API
Buat request ID unik, ID korelasi, dan kunci idempotensi untuk API RESTful dan GraphQL. UUID memudahkan pelacakan request di seluruh batas layanan terdistribusi.
Manajemen Sesi & Token
Hasilkan identifier sesi unik dan token sementara untuk alur autentikasi. UUID menyediakan keunikan yang cukup untuk mencegah tabrakan sesi di basis pengguna besar.
Pengujian & Pengembangan
Hasilkan data uji, identifier mock, dan ID fixture unik untuk pengujian otomatis dengan cepat. Pembuatan batch memudahkan pengisian database pengembangan dan suite pengujian.

Detail Teknis

Struktur UUID
UUID adalah 128 bit (16 byte) yang direpresentasikan sebagai 32 karakter heksadesimal dalam format 8-4-4-4-12. Bit 48-51 (digit hex ke-13) meng-encode nomor versi. Bit 64-65 meng-encode field varian, yang mengidentifikasi tata letak UUID. Bit sisanya membawa payload spesifik versi: timestamp, data acak, atau output hash.
Bit Versi
Bit 48-51 (nibble tinggi dari byte ke-7) meng-encode versi UUID: 0001 = v1 (berbasis waktu), 0011 = v3 (berbasis nama MD5), 0100 = v4 (acak), 0101 = v5 (berbasis nama SHA-1), 0110 = v6 (waktu yang direorganisasi), 0111 = v7 (waktu epoch Unix). Empat bit ini selalu diatur secara eksplisit selama pembuatan.
Field Varian
Bit 64-65 (dua bit paling signifikan dari byte ke-9) mendefinisikan varian. Pola 10x menunjukkan UUID RFC 4122/9562 (mayoritas besar). Pola 110 menunjukkan GUID Microsoft dengan urutan byte mixed-endian. Pola 0xx menunjukkan UUID yang kompatibel mundur dengan NCS (lama). Pola 111 dicadangkan untuk penggunaan masa depan.
Standar RFC 9562
RFC 9562, diterbitkan Mei 2024, menggantikan RFC 4122 sebagai spesifikasi UUID definitif. Ia secara resmi memperkenalkan UUID versi 6, 7, dan 8. Versi 6 mereorganisasi field v1 untuk kemampuan pengurutan. Versi 7 menggunakan timestamp Unix 48-bit dalam milidetik plus data acak, menjadikannya versi yang direkomendasikan untuk UUID berbasis waktu baru. Versi 8 menyediakan format untuk UUID kustom spesifik implementasi. RFC 9562 juga secara resmi men-deprecate v1 demi v6/v7.

Praktik Terbaik

Pilih Versi yang Tepat
Gunakan v4 untuk identifier unik umum di mana pengurutan atau determinisme tidak diperlukan. Gunakan v7 untuk primary key database — properti berurut waktunya memberikan performa indeks yang jauh lebih baik. Gunakan v5 saat Anda memerlukan ID deterministik yang diturunkan dari nama (lebih baik v5 daripada v3 untuk hashing yang lebih kuat).
Gunakan UUID v7 untuk Primary Key Database
Struktur berurut waktu UUID v7 menjaga penyisipan B-tree tetap berurutan, mengurangi fragmentasi indeks sekitar 90% dibanding UUID v4 acak. Ini berarti penulisan lebih cepat, indeks lebih kecil, dan utilisasi cache yang lebih baik. Sebagian besar database modern (PostgreSQL 17+, MySQL 8.0+) memiliki dukungan UUID bawaan yang dioptimalkan untuk pola ini.
Jangan Gunakan UUID sebagai Token Keamanan
UUID dirancang untuk keunikan, bukan kerahasiaan. UUID v1 membocorkan timestamp pembuatan dan alamat MAC. UUID v4 hanya memiliki 122 bit entropi dengan struktur yang dapat diprediksi. Untuk token keamanan, API key, atau secret sesi, gunakan CSPRNG khusus untuk menghasilkan 128 atau 256 bit data acak murni tanpa overhead struktur UUID.
Validasi Sebelum Parsing
Selalu validasi format UUID dengan ekspresi reguler sebelum mem-parse atau menyimpan. Tolak input yang cacat di batas sistem — endpoint API, pengiriman formulir, dan input database. Ini mencegah serangan injeksi, kerusakan data, dan error yang sulit di-debug dari identifier tidak valid yang menyebar melalui sistem Anda.

Pertanyaan yang Sering Diajukan

Apa itu UUID?
UUID (Universally Unique Identifier) adalah identifier 128-bit yang distandarkan oleh RFC 9562. Ia ditulis sebagai 32 digit heksadesimal yang ditampilkan dalam lima grup yang dipisahkan tanda hubung, mengikuti format 8-4-4-4-12 — misalnya, 550e8400-e29b-41d4-a716-446655440000. UUID dirancang untuk menjadi unik secara global tanpa memerlukan otoritas registrasi pusat. Istilah GUID (Globally Unique Identifier) adalah nama Microsoft untuk konsep yang sama dan menggunakan format yang identik. UUID digunakan secara luas di database, sistem terdistribusi, API, dan pengembangan perangkat lunak di mana pun identifier unik diperlukan. Dengan lebih dari 5,3 x 10^36 kemungkinan UUID v4, probabilitas menghasilkan duplikat sangat kecil, menjadikannya aman untuk pembuatan independen di seluruh sistem yang tidak terkoordinasi.
Apa perbedaan antara versi UUID?
UUID v1 meng-encode timestamp 60-bit dan alamat MAC 48-bit mesin, menjamin keunikan dalam waktu dan ruang tetapi berpotensi membocorkan identitas hardware. UUID v3 meng-hash namespace dan nama dengan MD5 untuk menghasilkan UUID deterministik — input yang sama selalu menghasilkan output yang sama. UUID v4 mengisi 122 dari 128 bitnya dengan data acak yang aman secara kriptografis, menjadikannya versi yang paling banyak digunakan untuk identifier unik umum. UUID v5 identik dengan v3 tetapi menggunakan SHA-1 alih-alih MD5, menawarkan ketahanan tabrakan hash yang lebih kuat. UUID v7, diperkenalkan di RFC 9562 (Mei 2024), menyematkan timestamp Unix 48-bit dalam milidetik diikuti bit acak, menghasilkan UUID yang unik dan secara alami dapat diurutkan berdasarkan waktu pembuatan. Pilihan versi tergantung pada kebutuhan Anda: v4 untuk kesederhanaan, v5 untuk determinisme, dan v7 untuk kunci database yang dapat diurutkan waktu.
Kapan saya harus menggunakan UUID v4 vs v7?
UUID v4 adalah versi paling populer dan pilihan default yang sangat baik. Ia menghasilkan 122 bit keacakan murni, tidak memerlukan konfigurasi, dan bekerja di mana saja. Gunakan v4 saat Anda hanya memerlukan identifier unik dan tidak peduli tentang pengurutan. UUID v7 adalah pilihan yang lebih baik saat UUID akan digunakan sebagai primary key database atau perlu diurutkan berdasarkan waktu pembuatan. Karena v7 menyematkan timestamp presisi milidetik di bit paling signifikan, UUID v7 secara alami diurutkan dalam urutan kronologis. Properti ini secara dramatis meningkatkan performa indeks B-tree — penyisipan selalu ke akhir indeks alih-alih posisi acak, mengurangi pemecahan halaman dan fragmentasi hingga 90%. Untuk proyek baru di 2026, rekomendasi umumnya adalah menggunakan v7 untuk kunci database dan v4 untuk yang lainnya. Kedua versi sama-sama unik dan acak secara kriptografis di bagian acaknya.
Berapa probabilitas tabrakan UUID?
UUID v4 memiliki 122 bit acak, memberikan 2^122 (sekitar 5,3 x 10^36) kemungkinan nilai. Untuk memiliki probabilitas 50% setidaknya satu tabrakan, Anda perlu menghasilkan sekitar 2,71 x 10^18 UUID — yaitu 2,71 kuintiliun. Untuk perspektif, jika Anda menghasilkan satu miliar UUID per detik, akan membutuhkan sekitar 86 tahun untuk mencapai probabilitas tabrakan 50%. Pada tingkat pembuatan yang lebih realistis, probabilitasnya sangat kecil. Misalnya, menghasilkan 10 juta UUID menghasilkan probabilitas tabrakan sekitar 1 banding 10^22. Dalam praktiknya, kegagalan hardware, bug perangkat lunak, dan kesalahan manusia semuanya miliaran kali lebih mungkin menyebabkan ID duplikat daripada tabrakan UUID v4. Matematika ini berdasarkan rumus birthday problem: p(n) kurang lebih sama dengan n^2 / (2 * 2^122).
Apa perbedaan antara UUID dan GUID?
UUID (Universally Unique Identifier) dan GUID (Globally Unique Identifier) pada dasarnya adalah hal yang sama. GUID adalah istilah yang diciptakan oleh Microsoft dan digunakan terutama di lingkungan Windows, .NET, COM, dan SQL Server. UUID adalah istilah standar yang didefinisikan oleh RFC 9562 (dan pendahulunya RFC 4122) dan digunakan di sebagian besar konteks lain termasuk Linux, Java, Python, PostgreSQL, dan pengembangan web. Keduanya menggunakan format 128-bit yang identik yang ditampilkan sebagai 32 digit heksadesimal dalam pola 8-4-4-4-12. Satu-satunya perbedaan kecil adalah alat Microsoft kadang menampilkan GUID dalam huruf besar dengan kurung kurawal, seperti {550E8400-E29B-41D4-A716-446655440000}, sementara UUID secara konvensi ditampilkan dalam huruf kecil tanpa kurung kurawal. Alat ini mendukung kedua format melalui pemilih format output — pilih format Kurung Kurawal {GUID} untuk output bergaya Microsoft.
Apakah UUID v4 aman secara kriptografis?
Saat dihasilkan menggunakan crypto.getRandomValues() atau CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) yang setara, UUID v4 berisi 122 bit data acak yang aman secara kriptografis. Alat ini menggunakan Web Crypto API, yang mengambil entropi dari sumber acak aman sistem operasi. Namun, UUID tidak boleh digunakan sebagai token keamanan, kata sandi, atau kunci enkripsi. Meskipun 122 bit keacakan membuat prediksi tidak mungkin, UUID memiliki struktur yang dapat diprediksi — nibble versi (4) dan bit varian tetap dan diketahui publik. Untuk token keamanan, gunakan API khusus seperti crypto.getRandomValues() dengan 128 atau 256 bit entropi penuh, atau gunakan format token yang mapan seperti JWT. Gunakan UUID untuk identifikasi, bukan untuk keamanan.
Bagaimana cara memvalidasi format UUID?
UUID yang valid cocok dengan pola ekspresi reguler: ^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ (tidak peka huruf besar/kecil). Pola ini memberlakukan format heksadesimal 8-4-4-4-12, memeriksa bahwa digit versi (posisi 15) antara 1 dan 7, dan memverifikasi bahwa nibble varian (posisi 20) dimulai dengan 8, 9, a, atau b (menunjukkan varian RFC 4122/9562). Di JavaScript, Anda dapat memvalidasi dengan: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(uuid). Sebagian besar bahasa pemrograman juga memiliki parsing UUID bawaan — misalnya, uuid.UUID() di Python, UUID.fromString() di Java, dan uuid.Parse() di Go. Selalu validasi UUID di batas sistem sebelum menyimpan atau memprosesnya untuk mencegah serangan injeksi dan kerusakan data.
Apakah UUID bagus untuk primary key database? (Performa, keamanan & versi terbaik)
Ya, UUID aman dan semakin populer sebagai primary key database, dengan UUID v7 sebagai versi yang direkomendasikan. Keuntungan utama: (1) UUID dapat dihasilkan di mana saja — klien, server, atau edge function — tanpa round trip ke database, memungkinkan arsitektur offline-first dan terdistribusi. (2) UUID mencegah serangan enumerasi karena bukan integer berurutan. (3) UUID menyederhanakan penggabungan data lintas sistem karena ID tidak pernah bertabrakan. UUID v7 adalah versi terbaik untuk primary key karena strukturnya yang berurut waktu menjaga indeks B-tree tetap berurutan, secara dramatis mengurangi pemecahan halaman, amplifikasi tulis, dan fragmentasi indeks hingga 90% dibanding UUID v4 acak. Trade-off-nya: UUID menggunakan 16 byte versus 4-8 byte untuk integer, meningkatkan penyimpanan dan memori untuk indeks. Di MySQL/InnoDB, di mana primary key adalah clustered index, UUID v4 acak dapat menyebabkan degradasi performa yang signifikan — v7 menyelesaikan ini dengan memastikan penyisipan selalu ditambahkan ke akhir indeks, mencapai performa yang sebanding dengan integer auto-increment. PostgreSQL menyimpan UUID secara native dalam 16 byte dengan tipe uuid. Untuk sebagian besar aplikasi modern, manfaat pembuatan ID yang unik secara global dan bebas koordinasi jauh melebihi biaya penyimpanan tambahan.
Apa itu namespace UUID (v3/v5)?
Namespace UUID adalah UUID yang telah ditentukan atau kustom yang berfungsi sebagai cakupan untuk menghasilkan UUID v3 dan v5 yang deterministik. RFC 4122 mendefinisikan empat namespace UUID standar: DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8), URL (6ba7b811-9dad-11d1-80b4-00c04fd430c8), OID (6ba7b812-9dad-11d1-80b4-00c04fd430c8), dan X.500 DN (6ba7b814-9dad-11d1-80b4-00c04fd430c8). Saat Anda menggabungkan namespace UUID dengan string nama, algoritma v3 atau v5 meng-hash keduanya untuk menghasilkan UUID deterministik — namespace plus nama yang sama selalu menghasilkan UUID yang sama. Ini berguna saat Anda memerlukan identifier yang dapat direproduksi yang diturunkan dari nama bermakna. Misalnya, meng-hash namespace DNS dengan 'example.com' selalu menghasilkan UUID v5 yang sama. Anda juga dapat menggunakan UUID valid apa pun sebagai namespace kustom untuk skema ID deterministik aplikasi Anda sendiri.
Apa itu UUID nil value?
UUID nil (juga disebut zero UUID) adalah 00000000-0000-0000-0000-000000000000 — semua 128 bit diatur ke nol. Ia didefinisikan dalam RFC 9562 Section 5.9 sebagai UUID khusus yang dapat mewakili ketiadaan nilai, mirip dengan null atau None dalam bahasa pemrograman. UUID nil berguna sebagai nilai sentinel, default dalam sistem konfigurasi, atau placeholder di record database di mana field UUID tidak boleh kosong tetapi belum ada nilai nyata. RFC 9562 juga mendefinisikan UUID max: ffffffff-ffff-ffff-ffff-ffffffffffff (semua bit diatur ke satu), yang dapat berfungsi sebagai penanda batas. Catatan penting: jangan pernah gunakan UUID nil sebagai identifier sebenarnya — ia tidak unik. Beberapa library UUID dan database mungkin menolak atau menangani UUID nil secara khusus, jadi pastikan sistem Anda memperlakukannya secara konsisten. Selalu dokumentasikan apakah UUID nil diterima dalam kontrak API dan skema database Anda.
Apa itu UUID v7 dan mengapa saya harus menggunakannya?
UUID v7 adalah versi UUID terbaru yang didefinisikan dalam RFC 9562 (Mei 2024). Ia menyematkan timestamp Unix 48-bit dalam milidetik di bit paling signifikan, diikuti data acak yang aman secara kriptografis. Desain ini menghasilkan UUID yang unik secara global, dapat diurutkan secara kronologis, dan sangat efisien sebagai primary key database. Tidak seperti UUID v1, yang juga berisi timestamp, v7 menggunakan format Unix epoch yang lebih sederhana dan tidak mengekspos alamat MAC Anda. Struktur berurut waktu mengurangi fragmentasi indeks B-tree hingga 90% dibanding UUID v4 acak, menghasilkan penyisipan lebih cepat, indeks lebih kecil, dan tingkat cache hit yang lebih baik. Untuk proyek baru mulai 2026, UUID v7 adalah pilihan yang direkomendasikan untuk skenario apa pun yang memerlukan pengurutan berbasis waktu — terutama primary key database, log event, dan antrian pesan terdistribusi.
Bagaimana cara mendekode UUID?
Mendekode UUID berarti mengekstrak informasi struktural yang di-encode dalam 128 bitnya. Setiap UUID berisi field versi (bit 48-51) yang mengidentifikasi bagaimana ia dihasilkan, dan field varian (bit 64-65) yang mengidentifikasi standar UUID yang dipatuhi. Di luar field umum ini, versi yang berbeda menyematkan data yang berbeda: UUID v1 dan v6 berisi timestamp 60-bit dan node (alamat MAC) 48-bit; UUID v7 berisi timestamp Unix 48-bit dalam milidetik; UUID v3 dan v5 berisi hash terpotong dari namespace dan nama. Untuk mendekode UUID, tempel ke tab Decode di alat ini. Ia akan langsung menampilkan versi, varian, timestamp (untuk versi berbasis waktu), dan status validitas. Secara programatis, Anda dapat mendekode dengan mem-parse digit hex dan menerapkan operasi bitwise untuk mengekstrak setiap field sesuai spesifikasi RFC 9562.
UUID vs ULID vs nanoid — mana yang harus saya gunakan?
UUID, ULID, dan nanoid melayani tujuan fundamental yang sama — menghasilkan identifier unik — tetapi berbeda dalam format, kemampuan pengurutan, dan standardisasi. UUID adalah standar yang paling banyak diadopsi (RFC 9562), didukung secara native oleh hampir semua database, bahasa, dan framework. UUID v7 menyediakan pengurutan berbasis waktu dalam format standar 128-bit, 36 karakter. ULID (Universally Unique Lexicographically Sortable Identifier) mendahului UUID v7 dan menggunakan encoding Crockford Base32 untuk menghasilkan string 26 karakter yang dapat diurutkan. Kini UUID v7 ada sebagai standar IETF, keuntungan utama ULID — kemampuan pengurutan — tersedia dalam format UUID universal. nanoid menghasilkan identifier lebih pendek (default 21 karakter) menggunakan alfabet aman URL, menjadikannya ideal saat panjang string penting dan Anda tidak memerlukan interoperabilitas lintas sistem. Untuk sebagian besar aplikasi, UUID v4 (umum) atau UUID v7 (kunci database) adalah pilihan yang direkomendasikan karena dukungan tooling universal, tipe database bawaan, dan standardisasi formal.
Saya membangun microservice dan perlu memilih antara UUID v4 dan v7 untuk primary key PostgreSQL — mana yang harus saya gunakan dan mengapa?
Gunakan UUID v7 untuk primary key PostgreSQL. UUID v7 menyematkan timestamp Unix presisi milidetik di bit paling signifikan, sehingga ID yang dihasilkan secara alami diurutkan secara kronologis. Ini menjaga indeks B-tree Anda tetap berurutan — penyisipan selalu ditambahkan ke akhir alih-alih mendarat di posisi acak, mengurangi pemecahan halaman dan fragmentasi indeks hingga 90% dibanding UUID v4 acak. PostgreSQL 17+ memiliki dukungan tipe uuid bawaan yang dioptimalkan untuk pola ini. UUID v4 masih baik untuk identifier yang tidak diindeks seperti ID korelasi atau token sesi di mana urutan pengurutan tidak penting.
Tim saya berdebat apakah menggunakan UUID atau integer auto-increment sebagai ID database — apa trade-off dunia nyatanya?
Integer auto-increment lebih kecil (4-8 byte vs 16 byte), lebih cepat dibandingkan, dan menghasilkan indeks yang berurutan secara alami. Namun, mereka memerlukan urutan terpusat (database), menjadikannya bermasalah di sistem terdistribusi, aplikasi offline-first, dan migrasi data. UUID dapat dihasilkan di mana saja — klien, edge function, beberapa database — tanpa koordinasi. Mereka juga mencegah serangan enumerasi (pengguna tidak dapat menebak /users/124 untuk menemukan record lain). Overhead penyimpanan nyata tetapi biasanya dapat diterima: indeks UUID kira-kira 2x ukuran indeks integer. Untuk sebagian besar aplikasi modern, UUID v7 menawarkan yang terbaik dari kedua dunia — unik secara global, bebas koordinasi, dan dapat diurutkan secara berurutan seperti auto-increment.