UUID Generator

Generate UUID v4 (random) identifiers in bulk, right in your browser. Supports multiple display formats: standard, uppercase, no hyphens, braces, and URN.

UUID versions at a glance

Version Based on Description
UUID v1 Timestamp + MAC address Generated from the creation time and the network card's MAC address. Can reveal the generating device, so it has raised privacy concerns and is rarely chosen for new systems today.
UUID v3 Namespace + MD5 hash Generated by hashing a namespace and a name string with MD5. Deterministic — the same input always produces the same UUID. v5 is now preferred for new use due to MD5's known collision weaknesses.
UUID v4 Fully random Generated from a cryptographically secure random source. Reveals no information about its origin and is simple to implement, making it the most widely used variant. This is the format this tool generates.
UUID v5 Namespace + SHA-1 hash Same namespace-based approach as v3, but uses SHA-1. Recommended when you need deterministic generation — reproducing the same ID from the same data every time.
UUID v6 Reordered timestamp + random Standardized in RFC 9562 (2024). Reorders v1's timestamp fields so lexicographic byte order matches chronological order, improving database index efficiency.
UUID v7 Unix timestamp + random Standardized in RFC 9562 (2024). Leads with a millisecond-precision Unix timestamp, so IDs sort in creation order. Increasingly adopted as a v4 replacement in new projects.

Tips

  • Every UUID is generated entirely in your browser via the Web Crypto API — nothing is ever sent to toolbase.cc's servers.
  • UUID v4 is the go-to choice whenever you need uniqueness without sequential, guessable IDs — database primary keys, API request IDs, and more.
  • Since 122 of UUID v4's 128 bits are random, the odds of a collision are astronomically small — you'd need to generate about 2.7×10¹⁸ of them before the collision probability even reaches roughly 50%.
  • The "no hyphens" format is handy for URL path segments or filenames. The "braces" format matches the GUID notation used in Windows COM/registry contexts.
  • Bump up the count and use "Copy all" to quickly generate seed data or test fixtures in bulk.

Frequently asked questions

Not impossible in theory, but with 122 bits of randomness, UUID v4's collision risk is negligible for any practical purpose. Even generating a billion UUIDs per second for a hundred years straight would only bring the odds of a single collision to around 50%.

Yes, they're essentially the same concept. GUID (Globally Unique Identifier) is Microsoft's name for its own implementation, and it's compatible with the 128-bit UUID format. The braces notation {xxxxxxxx-xxxx-...} is the common GUID style used in Windows COM and the registry.

Because UUID v4 is random, it tends to produce larger indexes and slower inserts than sequential integers (AUTO_INCREMENT). If you need inserts to stay sorted by creation time, consider UUID v7 (which embeds a timestamp) or ULID as an alternative.

If all you need is uniqueness, UUID v4 is the simplest and safest choice. Use v5 when you need to reproduce the same ID from the same input every time. For new projects that care about sort order or database insert efficiency, v7 is a strong option. v1 and v3 see little new adoption today.
ツールくん

Side Note — Why 128 Bits?

The UUID was devised in the 1980s by Apollo Computer for distributed systems, and later standardized by the OSF (Open Software Foundation) as part of DCE (Distributed Computing Environment). Today's specification lives in IETF RFC 4122 (2005), with an expanded RFC 9562 published in 2024.

128 bits might look excessive, but that length is what lets multiple servers or devices mint IDs completely independently, with zero coordination, while still avoiding collisions in practice. A central ID-issuing server that hands out sequential numbers avoids that randomness, but creates a single point of failure and requires a round trip for every ID. UUIDs eliminate that coordination cost entirely, trading it for enough randomness that the collision probability becomes negligible.

That randomness is also UUID v4's Achilles' heel: inserting random values into a B-tree style database index scatters the insert points, triggering frequent page splits and hurting performance. UUID v7 was devised to fix exactly this — by leading with a Unix timestamp, it stays sortable by creation time while keeping enough randomness to avoid predictability, giving inserts much better locality.