Free Online UUID Generator + Validator

Generate UUIDs locally: v4 (random), v5 (namespace+name), v7 (time-ordered). Bulk generate, search, sort, copy, and export.

UUID version
Count (bulk)
Sort
Search

Generated UUIDs

Validate UUID
Created Ver UUID Actions
v4 = random UUID. v7 = time-ordered UUID (good for DB indexes). v5 = SHA-1 namespace+name (deterministic).

About this tool

This free online UUID generator helps you create and validate UUIDs (v4, v5, and v7) directly in your browser. Use it to bulk-generate identifiers, verify format, and export results without sending data to a server. It's built for developers who need fast, predictable UUIDs for databases, APIs, logs, tests, and distributed systems.

Common use cases

  • Generate UUID v4 values for primary keys, request IDs, and correlation IDs
  • Create time-ordered UUID v7 identifiers for better index locality and sorting
  • Produce deterministic UUID v5 values from a namespace + name
  • Validate UUIDs from logs, payloads, or user input before storing
  • Bulk-generate IDs for fixtures, test data, migrations, or seed scripts

How it works

Generation happens client-side in your browser. For v4, the tool uses secure randomness (when available) to produce RFC-style UUIDs. For v5, it derives a deterministic UUID from a namespace UUID and a name string so the same input produces the same output. For v7, it creates time-ordered UUIDs that sort roughly by creation time. The validator checks structure and version/variant fields so you can quickly confirm an ID is well-formed.

FAQ

Does this UUID generator upload my data

No. Generation and validation run locally in your browser.

Which UUID version should I use

Use v4 for general random IDs, v5 for deterministic IDs based on inputs, and v7 when you want time-ordered UUIDs that sort better in databases.

Can I bulk-generate and export UUIDs

Yes. Generate multiple UUIDs, search/sort the list, then copy or export to TXT/CSV for use in scripts or datasets.

UUID versions explained

The UUID specification defines several version numbers, each using a different strategy to generate the 128-bit identifier. Choosing the right version depends on your use case — the wrong choice can introduce subtle ordering bugs, collision risks, or unnecessary coupling to external state.

UUID v1 (time + MAC): Encodes a 60-bit timestamp (100-nanosecond intervals since October 1582) and the network MAC address of the generating machine. This makes v1 UUIDs sortable by creation time, but it leaks the machine's MAC address — a privacy concern in user-facing contexts. It also creates coordination problems in distributed systems where clocks can skew or where multiple processes run on the same machine simultaneously.

UUID v4 (random): 122 bits of cryptographically random data with 6 bits reserved for the version and variant. This is the most widely used version for general-purpose identifiers: database primary keys, session tokens, object references, trace IDs. The randomness comes from crypto.getRandomValues() in browsers and /dev/urandom on Linux — both are cryptographically secure sources. The collision probability across 2^122 possible values is negligible for any practical scale.

UUID v5 (name-based, SHA-1): Deterministic — given the same namespace UUID and name string, v5 always produces the same UUID. This is useful when you need a stable identifier derived from a known input: a URL, a username, a file path. The namespace acts as a domain separator so that v5(url-namespace, "example.com") and v5(dns-namespace, "example.com") produce different UUIDs. The SHA-1 hash is truncated to 128 bits, so v5 is not suitable for cryptographic authentication — it is a deterministic mapping function, not a keyed MAC.

UUID v7 (Unix timestamp + random): A newer version (RFC 9562) that encodes a Unix millisecond timestamp in the high bits followed by random data. The timestamp-first layout means v7 UUIDs sort lexicographically in creation order — a property that v4 lacks. This matters significantly for database index performance: inserting random v4 UUIDs into a B-tree index causes random page splits, while v7 UUIDs insert at the end of the index like auto-increment integers. If you are using PostgreSQL, MySQL, or any database with clustered primary keys and expect high insert volume, v7 is worth the switch from v4.

UUID structure: reading the format

Every UUID in standard text form looks like xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx — 32 hexadecimal digits arranged in five groups separated by hyphens. The total is 128 bits. The M position encodes the version number (4 for v4, 7 for v7, etc.). The N position encodes the variant — for RFC 4122 UUIDs, the two high bits are always 10, so N is always 8, 9, a, or b.

When validating a UUID programmatically, checking these two positions is a quick sanity check before running a full regex. A v4 UUID with an M value other than 4 — or a variant nibble outside 8-b — is malformed and should be rejected by validation logic.

Common UUID pitfalls in production

Storing as VARCHAR instead of a native UUID type: Most databases (PostgreSQL, MySQL 8+, SQL Server) have a native UUID or GUID column type that stores the 16 bytes in binary and handles comparison efficiently. Storing UUIDs as VARCHAR(36) wastes space and slows index lookups — each comparison requires a string comparison instead of a 16-byte integer comparison. If your ORM defaults to VARCHAR, override it.

Case sensitivity bugs: UUID hex digits are case-insensitive by spec, but applications that compare UUID strings without normalizing case will have intermittent equality failures. Always lowercase (or always uppercase) before storing and before comparing. This is a common source of lookup misses when UUIDs flow through mixed-case APIs.

Using UUIDs as secrets: A UUID v4 is a random identifier, not a cryptographic token. It is fine as a lookup key — knowing a UUID lets you find a record — but it should not be used as an authentication token or a password reset token without additional MAC or signature on top. A 122-bit random value has good collision resistance but is not purpose-built for secret derivation. Use a dedicated token generation library for anything that must be unforgeable.

For related client-side cryptography, see Secure Paste (AES-GCM encryption in the browser) and JWT Decoder (inspect token claims without sending them to a server). If your workflow involves IP address identification alongside object references, the IP Lookup tool runs entirely in-browser as well.

Related tools

  • Hash Generator — hash a UUID or generate deterministic UUIDs via namespaced hashing
  • JSON Formatter — format JSON payloads that contain UUID primary keys or correlation IDs
  • Secure Paste — embed generated UUIDs inside securely shared snippets