PK Systems
Generators

UUID Generator

Generate UUID v4 (random) or v7 (timestamp-ordered) identifiers in your browser.

UUID Generator

Generated UUIDs

    What is a UUID?

    A UUID (Universally Unique Identifier, sometimes called GUID) is a 128-bit number written as 32 hex digits in the canonical 8-4-4-4-12 shape — for example a1b2c3d4-e5f6-4a7b-9c0d-1e2f3a4b5c6d. The point is that any system can mint one with no coordination and the chance of collision is negligible. v4 is fully random; v7 embeds a millisecond timestamp at the start, so v7s sort chronologically and play much nicer with database B-tree indexes than v4s.

    How to use this tool

    Pick a version (v4 for opaque random IDs, v7 when you want time-ordering for primary keys), choose how many you need (1-100), pick lower or UPPERCASE, and hit Regenerate. Use Copy next to a row to grab one, or Copy all to dump them all to the clipboard, one per line. v4 uses the browser's crypto.randomUUID(); v7 is built locally from a 48-bit timestamp plus 74 random bits.

    v4 vs v7 — which should I use?

    Use v4 for tokens, request IDs, opaque public-facing identifiers, anywhere you don't want order or timing leaked. Use v7 for primary keys in modern databases — it gives you globally-unique IDs without random-insert index thrash, and rows naturally sort by creation time. Avoid v1 (leaks MAC address) and v3/v5 (name-based, niche use). Don't truncate UUIDs to "save space" — collisions ramp up fast.

    UUID versions at a glance

    All UUIDs are 128 bits and look the same on the wire; the version number (the first hex digit of the third group) tells you how they were minted.

    Version Built from Typical use
    v1Timestamp + MAC addressLegacy. Leaks host info — avoid.
    v3 / v5Hash of namespace + name (MD5 / SHA-1)Deterministic IDs from a name. Niche.
    v4122 random bitsTokens, opaque IDs, request IDs.
    v6Reordered v1 (sortable)v1 replacement when you can't move to v7.
    v748-bit ms timestamp + 74 random bitsModern default for DB primary keys.
    v8Custom (RFC-defined slot)Bring-your-own scheme.

    Frequently asked questions

    Are these UUIDs really unique?
    For practical purposes, yes. A v4 has 122 random bits (~5×10³⁶ values); the chance of two random UUIDs colliding is so small you'd need to mint billions per second for centuries to expect one collision. v7s share the timestamp prefix among UUIDs minted in the same millisecond, but still have 74 random bits — collisions remain astronomically unlikely.
    Is v7 a real, ratified standard?
    Yes. UUID v7 is defined in RFC 9562 (May 2024), which superseded RFC 4122 and added v6/v7/v8. Postgres, MySQL, SQL Server and most modern languages now ship native helpers for it.
    Why use v7 instead of v4 for database primary keys?
    v4s are inserted in random positions in a B-tree index, which fragments the index and hurts write throughput on big tables. v7s start with a millisecond timestamp, so new rows go at the end of the index — same insert pattern as an auto-increment integer, but globally unique. You also get "created at" essentially for free.
    Can I sort v7 UUIDs by time?
    Yes. The first 48 bits are a Unix-millisecond timestamp, big-endian, so a plain string-sort or byte-sort on v7s gives you chronological order. UUIDs minted in the same millisecond will tie-break on the random tail, but rows still cluster by creation time.
    What's the difference between UUID and GUID?
    Nothing meaningful. "GUID" is the term Microsoft has historically preferred; "UUID" comes from the original DCE/RFC tradition. They are the same 128-bit identifier in the same canonical format. You can use them interchangeably.
    Are these generated on a server?
    No. v4 calls crypto.randomUUID(), a browser builtin. v7 is assembled locally from Date.now() and crypto.getRandomValues. There is no network round-trip, no logging — you can verify in DevTools > Network that nothing is fired when you click Regenerate.