Free UUID / GUID Generator

What is a UUID and why do developers rely on them?

A UUID (Universally Unique Identifier) — called a GUID (Globally Unique Identifier) in Microsoft ecosystems — is a 128-bit label standardised in RFC 4122. Its defining property is that any machine on any network can generate one independently, at any time, without consulting a central authority, and the probability of two UUIDs ever colliding is negligible enough to treat as zero in any real application. This decentralisation makes UUIDs the natural choice for distributed systems: microservices that need to generate IDs without a shared sequence counter, event-driven architectures where events originate from multiple sources simultaneously, and multi-region databases where sequential integer IDs would require coordination across data centres.

In practice, UUIDs are used for database primary keys, API resource identifiers, idempotency keys in payment and order systems, session tokens, correlation IDs in distributed tracing, and content-addressed file storage. Their 128-bit size makes them collision-resistant at any realistic scale, and their standardised format makes them portable across languages, databases and systems without conversion. When pairing UUIDs with strong API authentication, our Secure Token Generator produces complementary cryptographically secure tokens in hex and Base64 formats suited to HTTP headers and query parameters.

How unique is a UUID v4, really?

UUID v4 encodes 122 bits of randomness (the remaining 6 bits are version and variant flags), giving 2¹²² ≈ 5.3 × 10³⁶ possible values. To reach a 50% probability of a single collision across your entire dataset, you would need to generate approximately 2.7 × 10¹⁸ UUIDs — that is 2.7 quintillion. At a rate of one billion UUIDs generated per second, hitting that threshold would take approximately 86 years of continuous generation. For any real application, UUID v4 collisions are not a practical concern and do not need to be accounted for in system design.

The underlying randomness here uses crypto.getRandomValues(), the browser's cryptographically secure pseudorandom number generator seeded from hardware entropy sources. This is the same primitive used in production UUID libraries: crypto.randomUUID() in Node.js, the uuid npm package, and Java's UUID.randomUUID(). The output is unpredictable even to an observer who has seen every previous UUID generated by the same tool — there is no mathematical relationship between consecutive outputs.

What is the difference between a UUID and a GUID?

They are the same thing with different names from different ecosystems. GUID is Microsoft's term, used throughout the Windows API, COM component model, the .NET framework, SQL Server, and Visual Studio. UUID is the term from RFC 4122, used in most open-source languages, frameworks and protocols. Both follow the same 8-4-4-4-12 hexadecimal format, are 128 bits in length, and are completely interchangeable in any modern system. The binary encoding is identical; only the naming convention differs.

The only practical differences you will encounter are formatting conventions. Microsoft tooling often formats GUIDs in curly braces ({...}) and may use uppercase hex digits, while most web frameworks and databases prefer lowercase without braces. This generator supports all four formats — standard, braced, no-hyphens and URN — via the Format tabs, and the UPPERCASE toggle handles case conversion. When storing UUIDs in SQL Server, note that the uniqueidentifier type uses a non-standard byte ordering that differs from RFC 4122; most ORM libraries handle this transparently.

UUID v1 vs v4 vs v5 — which version should I choose?

Choose v4 for the vast majority of use cases — database primary keys, session IDs, idempotency tokens, API identifiers, event IDs. It requires no input, embeds no system information, and is the default in every major UUID library for good reason.

Choose v1 when chronological sortability matters for storage performance. UUID v1 encodes a 60-bit timestamp at 100-nanosecond resolution, which means UUIDs generated in sequence sort chronologically. On databases with B-tree indexes, this improves insert locality and reduces page splits compared to the random ordering of v4. The trade-off is that v1 UUIDs can encode system information; this tool substitutes a random node ID for the machine's MAC address to protect privacy, as permitted by RFC 4122. For applications that need timestamp-based identifiers with better index behaviour than standard v1, consider using ULID or UUID v7 (where library support is available).

Choose v5 when you need a deterministic, stable identifier derived from existing data. A v5 UUID is the SHA-1 hash of a namespace UUID plus a name string, formatted as a UUID. The same namespace and name always produce the same UUID — useful for content-addressed caching, deduplication pipelines where you need to identify whether two records are the same entity, and deriving UUIDs from URLs or email addresses without maintaining a lookup table. For general-purpose SHA-256 and SHA-512 hashing unrelated to UUID generation, use our Hash Generator.

What is the UUID v1 timestamp and why does it start in 1582?

UUID v1 counts time in 100-nanosecond intervals from midnight on 15 October 1582 — the date the Gregorian calendar was formally adopted in the Papal Bull Inter gravissimas. This unusual epoch was chosen when the UUID standard was being designed to maximise the range of the 60-bit timestamp counter, which can represent times up to 3 June 5236 before overflowing. Using 1582 rather than the Unix epoch (1970) or the NTP epoch (1900) provided the widest possible future range for a then-new standard.

The timestamp is split across three UUID fields in a counter-intuitive order — time_low (bits 0-31), time_mid (bits 32-47), and time_high_and_version (bits 48-59, plus version bits) — which means naive lexicographic sorting of standard-format v1 UUIDs does not produce chronological order. The middle field increments before the high field, producing a sort order that is roughly time-based but not perfectly sequential. This is one reason why some applications prefer UUID v7 (which places the timestamp in the most significant bits for natural sort ordering) or ULID (a different 128-bit identifier format with a cleaner timestamp-first layout).

Can I use UUIDs as database primary keys, and what are the trade-offs?

Yes, UUID primary keys are common practice — especially in distributed architectures where multiple application servers insert records simultaneously and a shared auto-increment sequence would require coordination. The key benefits are application-side generation (you can assign the ID before the database insert and reference it in related records immediately), portability (the same ID works across database shards, environments and data migration), and no information leakage (sequential integer IDs reveal record counts to anyone who can observe multiple IDs).

The main trade-off with UUID v4 is B-tree index fragmentation. Because v4 values are random, each insert lands at an arbitrary position in the index tree, causing frequent page splits and reducing cache locality compared to sequential integer keys. Practical mitigations include: using the database's native UUID column type (uuid in PostgreSQL, binary(16) in MySQL) rather than varchar(36) to halve storage; using timestamp-ordered UUIDs (v1 with the timestamp bytes reordered to MSB-first, sometimes called "COMB" UUIDs, or UUID v7 if your library supports it); or accepting the fragmentation at small to medium table sizes where the practical impact is negligible. For most applications under several tens of millions of rows on modern hardware, v4 UUID primary keys perform well without any special handling.

What does the URN format mean and when should I use it?

Prefixing a UUID with urn:uuid: produces a formal Uniform Resource Name as defined in RFC 4122 itself. This format is required in contexts where identifiers must be unambiguous URIs — XML namespaces, SAML assertions, LDAP schemas, OpenID Connect subject identifiers, and certain JSON-LD contexts. The urn:uuid: prefix signals to any standards-conformant parser that the value is specifically a UUID-type identifier governed by RFC 4122, rather than an arbitrary opaque string.

For most REST APIs, relational databases, and web application code, the standard hyphenated lowercase format is cleaner, more compact, and more widely expected by client libraries and ORM frameworks. The URN format adds 9 characters and the colon separators can occasionally cause parsing issues in contexts that use colons as field delimiters. Use the URN format only when a specific specification or standard explicitly requires it. For URL-safe tokens that need to travel in HTTP headers, query parameters or cookie values, our Secure Token Generator produces Base64 URL-safe and hex formats that are more compact than any UUID format.

How does UUID v5 differ from just hashing a string?

UUID v5 is structurally a SHA-1 hash, but with two important additions that make it genuinely useful rather than just a repackaged hash. First, a namespace UUID is prepended to the name before hashing — this prevents collisions across different UUID v5 domains. The string example.com hashed in the DNS namespace produces a completely different UUID than example.com hashed in the URL namespace, even though the name string is identical. This namespace isolation makes v5 safe to use in federated or multi-vendor systems where different parties independently derive UUIDs from the same names.

Second, the output is post-processed to be a valid RFC 4122 UUID: the version digit is set to 5 and the variant bits are set to the RFC 4122 values, ensuring the output is structurally identical to any other UUID and interoperable with all UUID-aware systems. A plain SHA-1 hash of a string produces a 160-bit value in an incompatible format that cannot be stored in a UUID column or processed by UUID libraries. Note that SHA-1 is used here only for UUID derivation — it is not suitable for security-sensitive applications like password hashing. For password storage, use our Bcrypt Hash Generator.

Are the UUIDs generated here safe for production use?

Yes. UUID v4 generation uses crypto.getRandomValues() — the same CSPRNG used in production UUID libraries in every major language: crypto.randomUUID() in Node.js 14.17+, java.util.UUID.randomUUID() in Java, uuid.uuid4() in Python, Str::uuid() in Laravel, and the uuid npm package in JavaScript. UUID v1 uses a cryptographically random clock sequence and node ID (not your real MAC address) alongside a current timestamp. UUID v5 uses the browser's native crypto.subtle.digest('SHA-1', ...). All three versions comply fully with RFC 4122. Nothing is transmitted to any server, logged, or stored — you can verify this by watching the Network tab in browser DevTools while generating.

For server-side UUID generation in your own application, prefer the canonical library for your platform over constructing UUIDs manually: the libraries handle edge cases in the specification (clock sequence rollover for v1, correct bit masking for all versions) that are easy to get wrong in a custom implementation. For generating complementary secure tokens — API keys, session secrets, CSRF tokens — that are not UUIDs, our Secure Token Generator and Password Generator apply the same client-side, zero-transmission principle.

What is the difference between a UUID, a ULID and a NanoID?

All three are 128-bit-class identifier formats designed for distributed systems, but they differ in encoding, sortability and readability. UUID is the oldest and most widely standardised — RFC 4122, universally supported in databases and frameworks, familiar to every developer. Its hyphenated hex format is verbose (36 characters) and v4's random distribution causes index fragmentation in large B-tree tables. ULID (Universally Unique Lexicographically Sortable Identifier) improves on this by encoding a 48-bit millisecond timestamp in the most significant bits followed by 80 random bits, using Crockford Base32 encoding that produces a 26-character string — sortable, URL-safe, and more compact than UUID. It is not yet an official standard but has libraries in most languages.

NanoID is a different approach: rather than targeting 128 bits specifically, it generates a configurable-length URL-safe random string using crypto.getRandomValues() and an alphabet you choose. At 21 characters with a 64-character alphabet it matches UUID v4's collision probability while being shorter and URL-safe. The trade-off is that NanoID values are not structurally recognisable as identifiers the way UUIDs are — they look like random strings. Choose UUID when interoperability and standards compliance matter most; ULID when you need sortability with database-friendly index behaviour; NanoID when you need a compact, URL-safe random identifier for a single application without cross-system compatibility requirements. Our Secure Token Generator produces NanoID-style cryptographically random tokens in hex and Base64 formats.