Generator UUID

UUID generator dan decoder online gratis, semua di browser Anda

UUID generator online gratis ini membuat universally unique identifier — juga dikenal sebagai GUID — seketika, tanpa daftar akun dan tanpa batas. Setiap UUID diproduksi secara lokal memakai cryptographically secure random number generator (CSPRNG) browser Anda, jadi tidak ada apa pun yang pernah dikirim ke server dan Anda bisa dengan aman menggunakan ID itu untuk kunci produksi, data uji, atau sistem sensitif. Alat ini berfungsi offline, menghasilkan satu ID atau ribuan secara massal, dan memasangkan generator dengan UUID decoder bawaan sehingga Anda bisa membuat dan memeriksa identifier di satu tempat.

Entah Anda butuh satu UUID acak, satu batch untuk mengisi database, atau cara cepat untuk decode UUID yang diberikan pada Anda, alat ini mencakup seluruh alur kerja — tanpa instalasi, tanpa library, dan tidak satu baris kode pun. Alat ini jauh melampaui apa yang ditawarkan situs seperti uuidgenerator.net atau guidgenerator.com, menggabungkan keenam versi UUID, setiap format output, ekspor massal, dan decoder lengkap dalam satu halaman privat.

Setiap versi UUID: v1, v3, v4, v5, v6, dan v7

Pilih versi yang cocok untuk kasus penggunaan Anda. UUID v4 sepenuhnya acak dan pilihan paling umum — nilai yang sama yang akan Anda dapatkan dari uuid.uuid4() di Python, java.util.UUID.randomUUID() di Java, atau crypto.randomUUID() di JavaScript. UUID v7 menyematkan timestamp Unix milidetik, jadi ID-nya bisa diurutkan berdasarkan waktu dan menjadi kunci utama database yang sangat baik. v1 dan v6 adalah UUID timestamp Gregorian (v6 adalah bentuk yang diurutkan ulang, bisa diurutkan), dihasilkan di sini dengan node acak sehingga tidak ada alamat MAC yang pernah bocor. Anda juga bisa menghasilkan nilai NIL (semua-nol) dan Max (semua-satu) khusus dari RFC 9562.

Untuk ID yang stabil dan bisa direproduksi, pilih versi berbasis nama: v5 (SHA-1) dan v3 (MD5) melakukan hash namespace bersama string nama, sehingga input yang sama selalu menghasilkan UUID yang sama. Pilih namespace standar — DNS, URL, OID, atau X.500 — atau tempel milik Anda sendiri, masukkan nama apa pun, dan turunkan identifier deterministik dari domain, URL, atau kunci. Output cocok persis dengan uuid.uuid5() / uuid.uuid3() Python.

Generasi massal dan format output yang fleksibel

Hasilkan hingga 10.000 UUID sekaligus dan ekspor sebagai teks polos, array JSON, kolom CSV, atau VALUES SQL siap-jalan — ideal untuk mengisi tabel, membangun fixture, atau membuat data uji yang realistis dalam hitungan detik. Format output-nya sesuai stack Anda: aktifkan huruf besar, hilangkan hyphen untuk bentuk kompak, bungkus dalam kurung kurawal untuk literal GUID .NET, atau tambahkan prefiks urn:uuid: untuk dokumen RDF dan XML.

Karena semuanya berjalan di sisi klien, generasi massal ribuan ID langsung instan dan tidak pernah menyentuh jaringan — menjadikan ini alternatif yang lebih cepat dan lebih privat ketimbang uuidtools.com atau panel UUID di dalam it-tools.tech.

Decode dan periksa UUID apa pun secara online

Tempel identifier apa pun ke dalam decoder bawaan untuk langsung membedah strukturnya. UUID decoder online ini melaporkan versi dan variannya, dan untuk UUID berbasis waktu ia mengekstrak data yang tersemat: timestamp penciptaan eksak dari v1, v6, dan v7, plus clock sequence dan node (menandai apakah node itu nilai acak atau alamat MAC sungguhan) dari v1 dan v6. Alat ini mengenali varian RFC 4122/9562 dan nilai khusus NIL serta Max, dan mentolerir kurung kurawal, prefiks URN, huruf campuran, dan hyphen yang hilang.

Itu menjadikannya pendamping yang berguna untuk debugging sehari-hari: konfirmasi apakah sebuah ID benar-benar acak (v4) atau berbasis waktu, temukan kapan sebuah record v1/v6/v7 dibuat, periksa bahwa ID v3/v5 berbasis nama tidak membawa data tersembunyi, atau sekadar validasi bahwa sebuah string adalah UUID yang terbentuk dengan baik sebelum ia mencapai kode Anda.

Versi UUID mana yang harus Anda gunakan?

Untuk sebagian besar kebutuhan, UUID v4 acak adalah default yang tepat: ia tidak membawa informasi tentang kapan atau di mana ia dibuat, yang persis apa yang Anda inginkan untuk identifier publik, token sesi, atau apa pun yang tidak seharusnya membocorkan waktu pembuatan. Gunakan v7 saat identifier itu juga menjadi kunci database — timestamp tersematnya menjaga baris tetap kira-kira terurut sesuai penyisipan, yang mengurangi fragmentasi indeks dan mempercepat range query pada tabel dengan penulisan tinggi.

v5 berbasis nama ideal saat Anda butuh UUID yang sama untuk entitas logis yang sama setiap kali — misalnya, menurunkan ID produk yang stabil dari URL kanonik. Menghasilkan UUID secara online adalah cara tercepat untuk mendapatkan ID yang benar dan tahan tabrakan saat Anda tidak ingin membuka REPL atau menyambungkan library. Dengan 122 bit entropi di balik setiap v4, kemungkinan tabrakan secara efektif nol bahkan pada skala masif.

UtiloKit vs uuidgenerator.net, guidgenerator.com, dan it-tools.tech

Uuidgenerator.net adalah salah satu alat UUID yang paling banyak dikunjungi tetapi menghasilkan satu UUID v4 per kunjungan halaman — tidak ada mode massal, tidak ada v7, tidak ada decoder, dan tidak ada opsi format. Guidgenerator.com serupa: sederhana, cepat, tetapi terbatas pada satu format dan satu versi. It-tools.tech mencakup UUID sebagai bagian dari toolbox yang lebih besar dan punya UI yang lebih bersih, tetapi memisahkan generasi dan decoding ke layar terpisah dan tidak mendukung ekspor SQL massal.

UtiloKit menempatkan keenam versi UUID (v1, v3, v4, v5, v6, v7), setiap format (standard, uppercase, no-hyphens, braced, URN), ekspor massal ke JSON/CSV/SQL, dan decoder lengkap dalam satu layar. Semuanya berjalan di browser Anda dengan CSPRNG — tanpa server, tanpa akun, tanpa unggah file. Alat ini juga berfungsi offline setelah pemuatan pertama, yang penting jika Anda sedang mengisi database di pesawat atau di lokasi dengan konektivitas yang tidak andal.

Versi UUID dijelaskan secara mendalam: v1 hingga v7

UUID v1 berbasis waktu: ia mengenkode timestamp Gregorian 60-bit (dalam interval 100-nanodetik sejak Oktober 1582) bersama clock sequence dan alamat MAC dari antarmuka jaringan yang menghasilkannya. Alamat MAC adalah masalah privasi kuncinya — UUID v1 membocorkan baik kapan maupun di mana ia dibuat, membuatnya tidak cocok untuk identifier publik. UUID v2 (DCE Security) jarang ditemui di luar sistem Unix lama; ia menggantikan sebagian timestamp dengan UID atau GID POSIX, mengorbankan jaminan keunikan dalam prosesnya.

UUID v3 dan v5 berbasis nama: mereka melakukan hash UUID namespace bersama string nama sembarang dan mengenkode hasilnya sebagai UUID. v3 memakai MD5; v5 memakai SHA-1 dan adalah pilihan yang lebih disukai untuk kode baru. Keduanya deterministik — namespace yang sama plus nama yang sama selalu menghasilkan UUID yang sama, menjadikannya ideal untuk menurunkan ID yang stabil dari URL, nama domain, atau kunci kanonik apa pun. UUID v4 adalah kebalikannya: 122 bit keacakan murni tanpa informasi tersemat, dihasilkan oleh CSPRNG. Ia jauh menjadi versi yang paling banyak dipakai saat ini dan yang dikembalikan crypto.randomUUID() di JavaScript dan uuid.uuid4() di Python.

UUID v6 menyusun ulang bidang timestamp v1 sehingga byte-nya terurut secara kronologis — memperbaiki kemampuan pengurutan v1 tanpa mengubah kandungan informasinya. UUID v7, diperkenalkan dalam RFC 9562 (2022), mengambil pendekatan yang lebih bersih: 48 bit pertama adalah timestamp Unix milidetik standar, diikuti 74 bit keacakan. Karena timestamp menempati bit paling signifikan, UUID v7 terurut secara leksikografis sesuai urutan pembuatannya — menjadikannya kunci utama database yang jauh lebih baik ketimbang v4 tanpa membocorkan alamat MAC seperti yang dilakukan v1. Untuk sebagian besar proyek baru yang membutuhkan ID global unik dan bisa diurutkan, v7 kini menjadi default yang direkomendasikan.

Probabilitas tabrakan UUID: mengapa duplikat secara efektif mustahil

UUID v4 berisi 122 bit data acak (6 bit dicadangkan untuk versi dan varian). Total jumlah nilai yang mungkin adalah 2¹²² — kira-kira 5,3 × 10³⁶. Masalah ulang tahun memberi tahu kita bahwa untuk mencapai probabilitas 50% menghasilkan setidaknya satu pasangan duplikat Anda perlu menghasilkan kira-kira 2,7 × 10¹⁸ UUID — 2,7 kuintiliun. Pada throughput satu miliar UUID per detik, mencapai ambang itu akan memakan waktu 85 tahun generasi tanpa henti. Dalam sistem realistis mana pun, probabilitas tabrakan sepanjang masa pakai software tidak bisa dibedakan dari nol.

Rumus paradoks ulang tahun membuat ini presisi: jumlah sampel yang dibutuhkan untuk probabilitas tabrakan p dalam ruang berukuran d kira-kira n ≈ √(2d × ln(1/(1−p))). Dengan d = 2¹²² dan p = 0,5, itu memberikan 2,7 × 10¹⁸. Bahkan untuk peluang 1-dalam-satu-triliun (p = 10⁻¹²), Anda tetap perlu menghasilkan sekitar 2,6 miliar UUID.

Satu risiko dunia nyata bukan pada matematikanya melainkan pada kualitas random number generator. PRNG yang rusak atau di-seed dengan buruk secara dramatis mengurangi entropi efektif — image mesin virtual awal yang di-clone sebelum pool entropi OS diinisialisasi telah menghasilkan UUID duplikat dalam produksi. Selalu gunakan CSPRNG (seperti crypto.getRandomValues() browser) alih-alih Math.random() atau sumber pseudo-random yang di-seed apa pun, dan jangan pernah fork sebuah proses tanpa me-reseed. Alat ini secara eksklusif memakai CSPRNG browser, jadi setiap UUID yang dihasilkannya membawa 122 bit entropi penuh.

UUID sebagai kunci utama database: v4 vs v7 vs auto-increment vs ULID

ID integer auto-increment kompak (4 byte untuk INT, 8 byte untuk BIGINT), terurut secara alami, dan cepat diindeks — tetapi mereka mengungkap jumlah baris kepada siapa pun yang melihat URL atau respons API, dan mereka rusak di bawah penulisan terdistribusi: dua server database yang masing-masing menambah counter-nya sendiri akan menghasilkan ID duplikat tanpa lapisan koordinasi eksternal. UUID v4 (16 byte) menyelesaikan masalah koordinasi itu — setiap node menghasilkan ID global unik secara independen — tetapi pola bit acaknya berarti penyisipan berturut-turut mendarat di posisi acak dalam indeks B-tree. Seiring tabel bertumbuh, hampir setiap penyisipan menjadi page miss, mengarah ke fragmentasi indeks, page split yang sering, dan throughput penulisan yang secara dramatis lebih lambat pada tabel besar.

UUID v7 menyelesaikan ketegangan ini. Timestamp Unix milidetiknya di bit paling signifikan berarti ID yang dihasilkan berdekatan waktu secara numerik berdekatan, jadi penyisipan mengelompok di ujung kanan indeks persis seperti auto-increment — sambil tetap global unik dan tidak membutuhkan koordinasi. Trade-off-nya versus auto-increment adalah ukuran (16 vs 8 byte) dan fakta bahwa waktu pembuatan kira-kira terlihat di ID-nya. Untuk sebagian besar aplikasi modern trade-off itu sepadan untuk dibuat. ULID (Universally Unique Lexicographically Sortable Identifier) mencapai hasil serupa memakai encoding Crockford Base32 (26 karakter, tanpa hyphen, tidak peka huruf besar/kecil), yang bisa lebih mudah dibaca di log dan URL. Snowflake ID, dipakai dalam skala oleh Twitter dan Discord, mengemas timestamp milidetik 41-bit, ID datacenter, ID worker, dan nomor sekuens ke dalam integer 64-bit — bisa diurutkan berdasarkan waktu, sangat cepat, tetapi membutuhkan penetapan ID worker terpusat.

Pohon keputusan praktisnya: gunakan UUID v7 untuk sebagian besar proyek baru yang butuh kunci utama global unik dan bisa diurutkan; gunakan UUID v4 saat Anda secara eksplisit ingin ID yang tidak mengungkap apa pun tentang waktu pembuatan atau urutan; gunakan ULID jika Anda butuh ID bisa diurutkan berdasarkan waktu dengan representasi URL yang lebih bersih dan dukungan ekosistem lintas bahasa; dan pertimbangkan Snowflake hanya ketika Anda beroperasi pada skala Twitter dan bisa mengelola infrastruktur penetapan ID worker.

Identifier unik alternatif: ULID, NanoID, CUID, dan MongoDB ObjectID

Spesifikasi UUID bukan satu-satunya cara untuk menghasilkan identifier global unik, dan untuk beberapa kasus penggunaan alternatifnya punya keuntungan nyata. ULID (Universally Unique Lexicographically Sortable Identifier) mengenkode 48 bit timestamp milidetik dan 80 bit keacakan menjadi 26 karakter Crockford Base32 — menjadikannya aman-URL, tidak peka huruf besar/kecil, dan bisa diurutkan berdasarkan waktu tanpa hyphen apa pun. NanoID mengambil sudut berbeda: memakai alfabet aman-URL (A–Za–z0–9_-) untuk menghasilkan ID 21-karakter dengan resistensi tabrakan yang sebanding dengan UUID v4, sambil sekitar 40% lebih kecil sebagai string. NanoID sangat populer di lingkungan JavaScript di mana ID pendek dan bersih lebih disukai ketimbang format hex UUID 36-karakter.

CUID (Collision-resistant Unique ID) dirancang khusus untuk penggunaan web: ia menggabungkan timestamp, fingerprint browser, counter per-proses, dan byte acak, menghasilkan ID yang tahan tabrakan bahkan lintas beberapa klien secara bersamaan. MongoDB ObjectID adalah identifier 12-byte (dirender sebagai 24 karakter hex) yang mengemas timestamp Unix 4-byte, identifier mesin-dan-proses 5-byte, dan counter acak 3-byte — mirip semangatnya dengan UUID v7 karena bisa diurutkan berdasarkan waktu dan menyematkan identitas mesin, mendahului spesifikasi UUID v7 lebih dari satu dekade.

Memilih di antara format-format ini bergantung pada batasan Anda. Jika Anda butuh kepatuhan RFC yang luas dan dukungan ekosistem (setiap database, ORM, dan bahasa besar punya dukungan UUID bawaan), gunakan UUID v7 untuk kunci yang bisa diurutkan dan UUID v4 untuk token opaque. Jika Anda butuh string pendek dalam URL, NanoID atau ULID adalah pilihan yang sangat baik. Jika Anda sudah berada dalam ekosistem MongoDB, ObjectID adalah kecocokan alaminya. Wawasan kuncinya adalah semua format ini menyelesaikan masalah inti yang sama — menghasilkan identifier yang global unik tanpa koordinasi terpusat — dan perbedaannya ada pada trade-off antara ukuran, kemampuan urutan, keterbacaan, dan eksposur informasi.