UUID Generator

How to Use the UUID Generator

This tool lets you generate one or more UUIDs in a single click, entirely inside your browser. Here is the step-by-step workflow:

1. Select a UUID version. Use the version selector to choose between v4 (random) and v1 (time-based). For most use cases, v4 is the right choice — it is the default for a reason.
2. Set the quantity. The quantity field lets you generate up to 100 UUIDs at once. Bulk generation is useful when seeding a database, creating test fixtures, or pre-generating a batch of identifiers for an import script. Each UUID is generated independently with its own random bits.
3. Click Generate. The results appear immediately. Each UUID is displayed on its own line so you can scan or copy individual entries.
4. Copy the result. Click the Copy button next to any UUID to copy it to your clipboard. If you generated a batch, a Copy All button lets you grab the entire list at once, ready to paste into your editor, spreadsheet, or SQL file.
5. Review history. Your last five generated UUIDs are saved in the history section below the tool. This is handy when you close a tab and need to retrieve a recently generated identifier without regenerating.

Because everything runs locally via the Web Crypto API, generation is instantaneous and works offline. There is no server round-trip, no logging, and no rate limiting.

What is a UUID?

A UUID (Universally Unique Identifier) is a standardized 128-bit label defined in RFC 4122. It is represented as 32 hexadecimal digits divided into five groups by hyphens, following the pattern 8-4-4-4-12: for example, 550e8400-e29b-41d4-a716-446655440000.

The key word is universally. Unlike auto-increment integers that require a central database to hand out the next number, UUIDs can be generated independently on any machine at any time with no coordination. Two servers in different data centers, a mobile device offline, and a browser tab can all generate UUIDs simultaneously and the values will not collide. This property makes UUIDs invaluable in distributed systems, where a central authority for ID allocation would be a bottleneck or a single point of failure.

The 128-bit size is a deliberate trade-off: larger than a 64-bit integer, but large enough that the probability of collision is negligible even at massive scale. UUIDs are also self-describing — you do not need to know the source system to recognize the format.

To learn more about the full UUID specification, see the blog post What is a UUID? A developer's guide.

UUID Versions

• v1 (Time-based): Constructed from the current timestamp (in 100-nanosecond intervals since October 1582) combined with a clock sequence and a node identifier (typically the MAC address, or a random value in browser environments). v1 UUIDs are monotonically increasing within a node, which makes them useful when you need sortable IDs. The downside is that the node field may leak machine identity.
• v4 (Random): Generated entirely from cryptographically secure random bits, except for four bits reserved for the version and two bits for the variant. This is the most widely used UUID version because it has no structure that reveals anything about when or where it was generated. Use v4 whenever you just need a globally unique opaque identifier.
• v7 (Time-ordered random): A newer version (RFC 9562) that combines a 48-bit Unix millisecond timestamp prefix with 74 random bits. This gives you UUIDs that sort chronologically — like v1 — but without leaking MAC addresses. v7 is the recommended choice for new projects that need database-friendly sortable IDs. See UUID versions compared for a deeper look.

Common Use Cases

• Database primary keys. UUIDs let you assign IDs on the client or application layer before a row is written to the database. This simplifies insert logic and avoids a round-trip to fetch the generated key. It also makes it safe to merge data from multiple shards or replicas without key conflicts.
• Distributed systems. When microservices or edge nodes need to create records without talking to a central coordinator, UUIDs provide uniqueness guarantees out of the box. Each service generates its own IDs and you can safely aggregate them later.
• Session identifiers. Web frameworks often use UUIDs to identify user sessions stored server-side. The random, unguessable nature of v4 UUIDs provides a baseline of security (though dedicated token libraries are preferable for high-security contexts — see the FAQ below).
• Unique file names. When users upload files, saving them under their original names causes collisions and path traversal risks. Renaming uploads to a UUID guarantees uniqueness and removes any sensitive information from the file path.
• API request tracing. Attaching a UUID to every outbound API request as a correlation or idempotency key lets you deduplicate retries on the server side and trace a request across multiple services in your logs.

Best Practices and Tips

Choose the right version for your use case. UUIDv4 is the safest default for most new identifiers. If you need database index performance or chronological ordering, prefer UUIDv7. Never use v1 in contexts where exposing a MAC address is a privacy concern.

Do not use UUIDs as security tokens. A UUID is an identifier, not a secret. Even UUIDv4 — while random — is not designed for use as an API key, password-reset token, or any other value where unguessability is a security requirement. Use a dedicated CSPRNG to generate tokens of at least 128 bits and encode them as hex or base64.

Store UUIDs efficiently. If your database supports a native UUID or binary(16) type, use it. Storing a UUID as a VARCHAR(36) wastes roughly 2× the space compared to a binary representation and slows down index lookups. PostgreSQL's uuid type and MySQL's BINARY(16) are common choices.

Consider ULID as an alternative. ULID (Universally Unique Lexicographically Sortable Identifier) is a UUID alternative that is sortable, URL-safe, and more human-readable than a standard UUID. It trades some randomness for better ergonomics. If you find UUIDs awkward to work with in URLs or logs, ULID is worth evaluating. If you need a deterministic identifier derived from an input value, consider using a hash generator instead.

For a full comparison of UUID versions and alternatives, see UUID versions compared. If you need random values for security purposes rather than identity purposes, the password generator is a better starting point.

FAQ

Are UUIDs truly unique?

UUID v4 has 122 bits of randomness, giving 2¹²² possible values — roughly 5.3 × 10³⁶. The probability of a collision when generating one billion UUIDs per second for a trillion years is still negligible. For all practical purposes, treat them as globally unique.

Is my data safe?

Yes. All UUID generation happens in your browser using the Web Crypto API. No data is sent to any server.

What is the difference between UUID versions?

v1 is time-based and includes a timestamp and MAC address, making it sortable but potentially leaking machine identity. v4 is fully random and the most widely used version today. v7 (a newer standard from RFC 9562) combines a millisecond timestamp prefix with random bits, giving you sortable IDs that are also privacy-safe — the best of both worlds for most new projects.

Can I use UUID as a database primary key?

Yes, but be aware of performance implications. UUIDs are 128 bits wide, larger than a typical integer primary key. Random UUIDs (v4) fragment B-tree indexes because inserts are scattered across the index rather than appended to the end. If you are using MySQL InnoDB or a similar clustered-index engine, prefer UUIDv7 or ULID, both of which are chronologically sortable and cause far fewer page splits. PostgreSQL handles random UUIDs more gracefully due to its index structure, but even there, sortable IDs improve bulk insert performance.

Should I use UUID as a security token or secret?

No. While UUIDv4 is random, it is not designed to be a secret. Some UUID versions (v1, v6) embed timestamps or node identifiers, which makes them partially predictable. For session tokens, API keys, or any secret value, use a dedicated cryptographically secure random token generator — for example, 32 bytes from crypto.getRandomValues encoded as hex. The password generator on this site can serve as a starting point for generating random secret values.