Buat UUID dan GUID secara instan: Integrasikan alat ini ke dalam workflow Anda untuk membuat identifier yang aman secara kriptografis dan bebas tabrakan untuk database, sistem terdistribusi, payload API, data pengujian, dan penamaan file — langsung di browser, tanpa kontak server.

Apa Itu UUID?

UUID (Universally Unique Identifier) adalah label 128-bit yang distandardisasi oleh RFC 9562 (diterbitkan April 2024, menggantikan RFC 4122 dari tahun 2005). Sifat utamanya adalah UUID dapat dibuat secara independen di mesin mana pun, kapan pun, tanpa otoritas koordinasi pusat — dan tetap unik secara global untuk semua keperluan praktis.

Representasi teks standarnya adalah 32 digit heksadesimal yang dibagi menjadi lima grup oleh tanda hubung:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Di sini M mengkodekan versi (algoritma yang digunakan untuk membuat UUID) dan N mengkodekan varian (standar tata letak bit — selalu 8, 9, a, atau b untuk UUID RFC 9562).

Contoh konkret UUID v4:

550e8400-e29b-41d4-a716-446655440000

Itu adalah 32 karakter hex = 128 bit data. Posisi tanda hubung murni bersifat estetis dan tidak membawa informasi — tanda hubung dihapus ketika UUID disimpan dalam bentuk biner atau kompak.

Seberapa Unik “Unik Secara Universal”?

UUID v4 menggunakan 122 bit keacakan (6 bit dicadangkan untuk metadata versi dan varian). Untuk memahami risiko tabrakan: jika Anda membuat 1 miliar UUID per detik, Anda membutuhkan waktu sekitar 85 tahun untuk mencapai probabilitas 50% terjadinya satu tabrakan. Untuk sistem nyata mana pun, probabilitas tabrakan pada dasarnya nol.

UUID vs GUID — Apakah Keduanya Sama?

Ya, untuk keperluan pengembangan modern, UUID dan GUID adalah hal yang sama.

GUID (Globally Unique Identifier) adalah istilah Microsoft yang diperkenalkan bersama COM/DCOM pada tahun 1990-an. GUID mengikuti tata letak RFC 9562 dan ukuran 128-bit yang sama. Perbedaan historisnya hanyalah kebiasaan Microsoft dalam menyerialisasi beberapa field dalam format biner — tetapi dalam bentuk string (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), UUID dan GUID identik dan dapat dipertukarkan.

Dalam praktiknya: ekosistem Windows dan .NET cenderung menyebut GUID, sementara Linux, macOS, web API, dan database cenderung menyebut UUID. Keduanya merujuk pada standar yang sama.

Penjelasan Semua Versi UUID

Nomor versi tidak berarti “lebih baru adalah lebih baik.” Nomor ini mengidentifikasi algoritma yang digunakan untuk membuat UUID. Setiap versi memecahkan masalah yang berbeda.

Versi	Algoritma	Dapat Diurutkan	Kasus Penggunaan
v1	Timestamp + alamat MAC	Sebagian	Hanya untuk sistem lama
v2	DCE Security (POSIX UID/GID)	Tidak	Usang, hindari
v3	Hash namespace dengan MD5	Tidak	ID deterministik (MD5 rusak, pakai v5)
v4	Acak	Tidak	Tujuan umum — pilihan aman default
v5	Hash namespace dengan SHA-1	Tidak	ID deterministik dari nama + namespace
v6	Timestamp yang diurutkan ulang + acak	Ya	Jalur migrasi dari v1
v7	Timestamp Unix + acak	Ya	Primary key database, sistem modern

UUID v1 — Timestamp dan Alamat MAC

v1 mengkodekan timestamp saat ini (dalam interval 100 nanosecond sejak Oktober 1582) beserta alamat MAC mesin pembuat. Ini memberikan pengurutan waktu sebagian tetapi membocorkan identitas mesin dan waktu pembuatan dalam UUID itu sendiri. Hindari v1 di API publik atau sistem mana pun yang mementingkan privasi.

UUID v2 — DCE Security

v2 adalah varian dari v1 yang menggantikan sebagian timestamp dengan POSIX UID, GID, atau domain identifier. Dirancang untuk Distributed Computing Environments (DCE) di awal tahun 1990-an dan praktis sudah usang. Anda kecil kemungkinannya menemui v2 di luar infrastruktur enterprise lawas.

UUID v3 — Hash Namespace dengan MD5

v3 menghasilkan UUID deterministik dengan meng-hash UUID namespace dan nama bersama menggunakan MD5. Dengan namespace dan nama yang sama, v3 selalu menghasilkan UUID yang sama. Ini berguna ketika Anda membutuhkan identifier stabil yang dapat direproduksi untuk nilai yang diketahui — tetapi MD5 sudah rusak secara kriptografis. Gunakan v5 sebagai gantinya untuk semua pekerjaan baru.

UUID v4 — Murni Acak (Default Tujuan Umum)

v4 dihasilkan dari 122 bit data acak yang aman secara kriptografis. Tidak ada timestamp, tidak ada alamat MAC, tidak ada metadata — hanya keacakan. Keunggulannya:

• Mudah dibuat di setiap bahasa dan platform
• Privat — tidak mengungkapkan kapan atau di mana dibuat
• Aman untuk token, session ID, dan identifier publik
• Didukung secara universal di setiap database, framework, dan API

UUID v4 adalah pilihan yang tepat untuk 95% kasus penggunaan. Jika Anda hanya membutuhkan ID yang unik dan performa indeks database bukan masalah, gunakan v4.

UUID v5 — Hash Namespace dengan SHA-1

v5 bekerja identik dengan v3 tetapi menggunakan SHA-1 alih-alih MD5. Dengan namespace dan nama yang sama, selalu menghasilkan UUID yang sama. Gunakan v5 ketika Anda perlu menghasilkan identifier yang dapat direproduksi dan tahan tabrakan dari input yang diketahui — misalnya, UUID stabil untuk URL, alamat email, atau SKU produk tertentu.

UUID v6 — Timestamp yang Diurutkan Ulang

v6 adalah varian yang diatur ulang dari v1 yang menempatkan timestamp dalam urutan big-endian sehingga UUID v6 terurut secara kronologis. Ini ada terutama sebagai jembatan migrasi dari v1 ke v7 untuk sistem yang sudah menggunakan v1. Untuk sistem baru, langsung gunakan v7.

UUID v7 — Default Modern untuk Primary Key Database

UUID v7 diformalkan dalam RFC 9562 (2024) dan dengan cepat menjadi default yang direkomendasikan untuk proyek baru yang menggunakan UUID sebagai primary key database.

v7 menyematkan timestamp Unix 48-bit dalam milidetik di bit paling signifikan, diikuti oleh data acak. Karena timestamp ada di depan, UUID v7 dapat diurutkan secara leksikografis — keduanya terurut berdasarkan waktu pembuatan baik sebagai string maupun nilai biner.

019047b4-1c5e-7000-b703-24c3f6a5c849
│           │         │
└─ Timestamp Unix 48-bit (ms)  └─ Bit acak

Properti pengurutan ini berdampak besar pada performa database.

UUID v4 vs UUID v7 — Mana yang Harus Digunakan?

	UUID v4	UUID v7
Pembuatan	Murni acak	Timestamp + acak
Dapat diurutkan	Tidak	Ya (berdasarkan waktu pembuatan)
Timestamp tertanam	Tidak	Ya (presisi 48-bit ms)
Privasi	Tinggi — tidak mengungkapkan apa pun	Membocorkan waktu pembuatan
Performa indeks DB	Buruk pada skala besar	Sangat baik
Dukungan browser	crypto.randomUUID()	Perlu dibuat manual
RFC	RFC 9562	RFC 9562

Gunakan UUID v4 saat:

• Anda membutuhkan token publik, session ID, atau referensi yang tidak transparan
• Menyembunyikan waktu pembuatan itu penting (token keamanan, link undangan)
• Performa indeks database bukan bottleneck

Gunakan UUID v7 saat:

• UUID akan menjadi primary key database
• Anda ingin record terurut secara alami berdasarkan waktu pembuatan tanpa kolom created_at terpisah
• Anda membangun sistem terdistribusi yang membuat ID di banyak node

UUID sebagai Primary Key Database — Panduan Performa

Di sinilah pilihan versi UUID memiliki dampak teknis yang paling terlihat.

Mengapa UUID v4 Menurunkan Performa Database

Database relasional seperti MySQL InnoDB dan PostgreSQL menggunakan indeks B-tree untuk primary key. B-tree dioptimalkan untuk penyisipan berurutan — setiap baris baru masuk di dekat akhir halaman terakhir yang ditulis. Pola ini mengisi halaman secara efisien dan meminimalkan I/O disk.

UUID v4 bersifat acak. Setiap UUID baru disisipkan ke posisi acak dalam B-tree. Hal ini menyebabkan:

• Pemisahan halaman: Engine harus sering memisahkan halaman penuh untuk menyisipkan secara acak, yang memfragmentasi indeks
• Pengeluaran cache: Akses acak berarti engine harus terus memuat halaman lama dari disk alih-alih bekerja di ujung “panas” pohon
• Pemborosan ruang: Utilisasi halaman bisa turun hingga 50% akibat fragmentasi
• Query rentang lebih lambat: Tidak ada lokalitas temporal — baris yang dibuat dalam waktu dekat tersebar di seluruh indeks

Pada jumlah baris rendah, ini tidak terlihat. Pada puluhan juta baris dengan throughput tulis yang tinggi, primary key UUID acak menyebabkan penurunan performa yang signifikan.

Mengapa UUID v7 Mengatasi Masalah Ini

Awalan timestamp v7 berarti setiap UUID baru lebih besar dari semua UUID yang dibuat sebelumnya (dalam milidetik yang sama, penghitung urutan atau bit acak mempertahankan urutan). B-tree menerima penyisipan hanya di daun paling kanan — pola efisien yang sama seperti integer auto-increment.

Benchmark pada skala besar menunjukkan performa tulis hingga 400% lebih cepat dengan UUID berurutan dibandingkan v4 acak, dengan fragmentasi indeks yang jauh lebih rendah.

Penyimpanan Biner

Baik menggunakan v4 maupun v7, menyimpan UUID sebagai string CHAR(36) memboroskan ruang. Gunakan BINARY(16) atau tipe UUID native database Anda:

• PostgreSQL: Tipe UUID bawaan (disimpan secara internal sebagai 16 byte)
• MySQL: BINARY(16) atau fungsi UUID_TO_BIN() / BIN_TO_UUID() dengan argumen swap_flag=1 untuk memindahkan bit timestamp ke depan
• MongoDB: BSON subtype UUID native

Cara Membuat UUID dalam Kode

JavaScript / Node.js

// Node.js 14.17+ dan semua browser modern
const id = crypto.randomUUID(); // UUID v4

// Node.js 19+ / library pihak ketiga untuk v7
import { v7 as uuidv7 } from 'uuid';
const id = uuidv7();

Python

import uuid

id_v4 = str(uuid.uuid4())
id_v5 = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))

Java

import java.util.UUID;

UUID id = UUID.randomUUID(); // v4
String idStr = id.toString();

C# / .NET

Guid id = Guid.NewGuid(); // v4
string idStr = id.ToString(); // "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

PostgreSQL

-- UUID v4 native (PostgreSQL 13+)
SELECT gen_random_uuid();

-- UUID v7 via ekstensi pg_uuidv7
SELECT uuid_generate_v7();

Go

import "github.com/google/uuid"

id := uuid.New()         // v4
idStr := id.String()

Referensi Format dan Struktur UUID

550e8400 - e29b - 41d4 - a716 - 446655440000
│          │      │      │      │
│          │      │      │      └── Node (48 bit)
│          │      │      └───────── Clock sequence (14 bit) + Varian (2 bit)
│          │      └──────────────── Versi (4 bit) + Time mid (12 bit)
│          └─────────────────────── Time mid (16 bit)
└────────────────────────────────── Time low (32 bit)

Digit versi (M): Karakter ke-13. 4 = acak, 7 = berawalan timestamp.

Bit varian (N): Karakter ke-17. Selalu 8, 9, a, atau b untuk UUID RFC 9562 — dua bit ini mengidentifikasi UUID sebagai mengikuti tata letak RFC 9562.

UUID Khusus

• UUID nil: 00000000-0000-0000-0000-000000000000 — semua bit nol, digunakan sebagai nilai null/sentinel
• UUID max: ffffffff-ffff-ffff-ffff-ffffffffffff — semua bit satu, RFC 9562 mendefinisikan ini sebagai UUID kasus khusus yang valid

Format Output

Nilai UUID yang sama dapat direpresentasikan dengan beberapa cara tergantung kebutuhan sistem:

Format	Contoh
Standar (dengan tanda hubung)	550e8400-e29b-41d4-a716-446655440000
Kompak (tanpa tanda hubung)	550e8400e29b41d4a716446655440000
Kurung kurawal	{550e8400-e29b-41d4-a716-446655440000}
Huruf besar	550E8400-E29B-41D4-A716-446655440000
URN	urn:uuid:550e8400-e29b-41d4-a716-446655440000

Kasus Penggunaan di Dunia Nyata

1. Primary Key Database

UUID memungkinkan sistem terdistribusi membuat primary key tanpa generator urutan terpusat. Tidak seperti integer auto-increment, primary key UUID tidak mengungkapkan jumlah total baris atau urutan penyisipan kepada pemanggil eksternal. Gunakan UUID v7 untuk tabel baru ketika Anda mengontrol schema.

2. ID Sistem Terdistribusi — Tanpa Koordinasi

Dalam arsitektur microservices, beberapa layanan yang membuat record secara independen tidak bisa berbagi urutan auto-increment tanpa layanan koordinator. Setiap node membuat UUID-nya sendiri dan menyisipkan tanpa risiko tabrakan — bahkan jika layanan-layanan tersebut belum pernah berkomunikasi satu sama lain.

3. Kunci Idempotency untuk Pembayaran dan API

Payment processor seperti Stripe dan API yang mendukung idempotency memerlukan kunci unik per request. Mengirim kunci idempotency yang sama dua kali mengembalikan hasil yang di-cache alih-alih menjalankan operasi lagi. UUID adalah format standar untuk kunci-kunci ini.

4. Penamaan File dan Aset Bebas Tabrakan

File yang dinamai dengan UUID tidak bisa bertabrakan terlepas dari berapa banyak pengguna yang mengunggah secara bersamaan. Objek dengan nama UUID di S3, GCS, atau blob store mana pun aman dibuat secara paralel tanpa strategi penguncian.

5. Identifier Session dan Token

UUID banyak digunakan sebagai session ID, token reset kata sandi, link verifikasi email, dan kode undangan. Gunakan v4 untuk kasus-kasus ini — keacakan yang tidak transparan tidak mengungkapkan metadata tentang kapan token diterbitkan.

6. ID Deterministik dari Input yang Diketahui (v5)

Ketika Anda membutuhkan UUID stabil yang dapat direproduksi untuk input tertentu — UUID kanonik untuk URL, SKU produk, atau email pengguna — buat dengan UUID v5 menggunakan namespace tetap. Input yang sama selalu menghasilkan UUID yang sama, sehingga aman membuat ID tanpa harus mencarinya di database terlebih dahulu.

Cara Menggunakan Generator UUID Ini

1. Masukkan jumlah UUID yang Anda butuhkan (1 hingga 1000).
2. Pilih format output: standar dengan tanda hubung, kompak, kurung kurawal, atau huruf besar.
3. Klik Buat UUID, atau aktifkan Buat Otomatis untuk membuat ID baru setiap kali halaman dimuat.
4. Klik Salin untuk menyalin semua ID ke clipboard, atau Unduh untuk menyimpannya sebagai file .txt.
5. Untuk menormalisasi UUID yang sudah ada, tempel ke panel kedua. Alat ini memvalidasi setiap nilai dan mengonversinya ke format standar huruf kecil dengan tanda hubung.

Data sebagai Parameter

Isi jumlah generator terlebih dahulu melalui URL:

https://www.uprek.com/id/tools/generator-uuid-guid?count=25

Isi panel normalizer dengan string UUID yang sudah ada:

https://www.uprek.com/id/tools/generator-uuid-guid?input=123e4567e89b42d3a456426614174000

Data Anda Tidak Pernah Meninggalkan Browser

Saat Anda menggunakan alat ini dalam konteks profesional — mengisi database seed, membuat ID untuk tooling internal, atau menormalisasi UUID dari ekspor produksi — Anda seharusnya tidak perlu mengirim data tersebut ke server pihak ketiga.

Di UPREK, arsitektur kami tegas: data Anda adalah milik Anda. Kami tidak menginginkannya, tidak mengumpulkannya, dan tidak bisa melihatnya.

• Pembuatan 100% Lokal: UUID dibuat menggunakan API browser native crypto.randomUUID(), atau crypto.getRandomValues() sebagai fallback — keduanya berjalan sepenuhnya di dalam JavaScript engine browser Anda.
• Tanpa Upload ke Server: Tidak ada UUID yang Anda buat atau tempel ke alat ini yang pernah dikirimkan ke server kami.
• Tanpa Log atau Penyimpanan: Kami tidak mencatat, menyimpan, atau memeriksa identifier atau teks input yang Anda kerjakan.
• Penghapusan Instan: Semua data yang dibuat hanya ada di memori aktif browser Anda. Tutup tab dan data tersebut hilang.

Pertanyaan yang Sering Diajukan

Catatan Perubahan