Free Online UUID/GUID Generator

What is a UUID/GUID?

A UUID (Universally Unique Identifier), also known as a GUID (Globally Unique Identifier) in Microsoft ecosystems, is a 128-bit identifier standardized by RFC 4122. It is represented as a 32-character hexadecimal string divided into five groups separated by hyphens, following the format: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M indicates the UUID version and N indicates the variant.

UUIDs are designed to be globally unique without requiring a central registration authority or coordination between generating parties. This makes them invaluable in distributed systems, where multiple servers, services, or clients need to independently create identifiers that are guaranteed not to collide. Databases, APIs, message queues, microservices, event sourcing systems, and client-side applications all rely on UUIDs for unique identification.

The term GUID was coined by Microsoft and is used interchangeably with UUID throughout the Windows ecosystem, .NET framework, SQL Server, and COM/OLE. Despite the different names, UUIDs and GUIDs follow the same specification and produce identical 128-bit identifiers in the same format.

A UUID looks like this: 550e8400-e29b-41d4-a716-446655440000. The 13th character always indicates the version (in this example, 4 for UUID v4), and the 17th character indicates the variant (typically 8, 9, a, or b for the RFC 4122 variant).

How to Generate UUIDs Online

Creating UUIDs with our free UUID generator is fast and simple:

1. Select UUID Version: Choose the version you need — UUID v4 (random, most common and recommended for general use) or UUID v1 (timestamp-based, includes creation time). UUID v4 uses 122 bits of cryptographic randomness, making collisions virtually impossible.
2. Choose Output Format: Select how your UUIDs should be formatted — standard with hyphens (550e8400-e29b-41d4-a716-446655440000), without hyphens (550e8400e29b41d4a716446655440000), uppercase, wrapped in braces for Microsoft GUID style ({550E8400-E29B-41D4-A716-446655440000}), or as a URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000).
3. Set Quantity: Choose how many UUIDs to generate at once — from 1 to 100. Bulk generation is perfect for seeding databases, creating test fixtures, or populating configuration files.
4. Click Generate: Your UUIDs are created instantly in the browser using the Web Crypto API's crypto.getRandomValues() for true cryptographic randomness. No server is contacted during generation.
5. Copy Your UUIDs: Click the Copy All button to copy every generated UUID to your clipboard at once, or click individual UUIDs to copy them one at a time. Paste them directly into your code, database queries, or configuration files.

UUID Versions Explained

The UUID specification defines several versions, each using a different method to generate the 128-bit identifier. Here's a comprehensive comparison:

UUID v4 is the most commonly used version and the right choice for the vast majority of applications. It uses 122 bits of cryptographic randomness (the remaining 6 bits encode the version and variant), producing approximately 5.3 × 10³⁶ possible UUIDs — a number so vast that collisions are mathematically negligible.

UUID v7 is gaining rapid adoption as the preferred choice for database primary keys. Unlike v4, v7 UUIDs are time-sortable — they begin with a millisecond-precision Unix timestamp, which means they naturally sort in chronological order. This eliminates the B-tree index fragmentation problem that random v4 UUIDs cause in databases, resulting in significantly better insert performance and index locality.

UUID vs Auto-Increment IDs

When designing databases and APIs, developers often face the choice between UUIDs and traditional auto-incrementing integer IDs (1, 2, 3, ...). Each approach has distinct advantages and trade-offs:

Advantages of UUIDs

• Globally unique without coordination: UUIDs can be generated independently on any client, server, or service without consulting a central authority. This is essential for distributed systems, microservices, offline-capable apps, and multi-region deployments.
• No information leakage: Sequential integer IDs reveal business information — competitors can estimate your user count, order volume, or growth rate by creating accounts and observing ID sequences. Random UUIDs expose nothing.
• Safe for public exposure: UUIDs are safe to use in URLs, API responses, and client-side code because they cannot be enumerated or guessed. Auto-increment IDs enable IDOR (Insecure Direct Object Reference) attacks if authorization isn't rigorous.
• Merge-friendly: When merging data from multiple databases, UUID columns never collide. Integer IDs require remapping, which is complex and error-prone.

Advantages of Auto-Increment IDs

• Smaller storage: A 4-byte integer or 8-byte bigint uses far less storage than a 16-byte UUID, reducing table size, index size, and memory consumption.
• Better index performance: Sequential integers insert at the end of B-tree indexes, maintaining optimal index structure. Random UUID v4 causes scattered inserts that fragment indexes (though UUID v7 solves this).
• Human-readable: Order #12345 is easier to communicate and remember than order #550e8400-e29b-41d4-a716-446655440000.

Best practice: Many production systems use both — an auto-increment integer as the internal clustered primary key (for performance) and a UUID as the external-facing public identifier (for security and distributed compatibility).

UUID in Databases & APIs

UUIDs are a first-class data type in most modern databases. PostgreSQL has a native uuid type with built-in generation via gen_random_uuid() (v4) and the uuid-ossp extension. MySQL 8.0+ provides UUID() (v1) and UUID_TO_BIN()/BIN_TO_UUID() for efficient binary storage. SQL Server has the uniqueidentifier type and NEWID() (random) / NEWSEQUENTIALID() (sequential) functions. MongoDB uses 12-byte ObjectIDs by default but natively supports UUID types.

When storing UUIDs in databases, use the native UUID column type whenever available. If the database doesn't support a UUID type natively, store as BINARY(16) rather than CHAR(36) — binary storage uses 16 bytes versus 36 bytes for the string representation, saving 55% storage and improving join/index performance.

In REST APIs, UUIDs are the standard identifier format for resources. They appear in URL paths (/api/users/550e8400-e29b-41d4-a716-446655440000), request/response bodies, and headers. Most API frameworks and ORMs provide built-in UUID support, including Django (UUIDField), Rails (has_secure_token), Spring Boot (UUID type), and Express.js (uuid package).

Tips for Working with UUIDs

1. Default to UUID v4 for general use: Unless you have a specific reason to use another version, v4 is the safest and most widely supported choice. It has no dependencies on time, MAC address, or namespace.
2. Use UUID v7 for database primary keys: If your database supports it, v7's time-sortable property eliminates the index fragmentation issues of v4, giving you the best of both worlds — global uniqueness plus excellent database performance.
3. Store as binary, not string: Use BINARY(16) or the native UUID type in your database. The string representation (CHAR(36)) wastes storage and slows comparisons. Convert at the application layer when needed for display.
4. Don't assume ordering: UUID v4 values are random and have no inherent order. Don't use them for sorting records by creation time — add a separate created_at timestamp column, or use UUID v7.
5. Validate format in APIs: Always validate UUID format in API inputs using a regex like /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i. Reject invalid UUIDs early to prevent downstream errors.
6. Consider ULID as an alternative: ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier similar to UUID but with a built-in timestamp prefix and Crockford's Base32 encoding. It's time-sortable, more compact in string form (26 characters vs 36), and gaining popularity for database use cases.