UUID Generator

Version 4 vs version 7

Version 4 fills the ID with random bits. Two v4 IDs do not sort by time. Version 7 puts a Unix timestamp in milliseconds first, then random bits, so newer IDs tend to sort after older ones. That follows RFC 9562. Version 1 is omitted on purpose. If you need time-ordered IDs, use v7.

You can also paste a UUID into the decoder to see its version, variant, and v7 timestamp.

A UUID is an identifier. It is not a password, an API key, a session token, or an encryption key. Do not treat a UUID as a secret just because it looks random.

Bulk output and format controls

Generate one ID for a quick migration or a batch for fixtures, seed data, and test records. The count control keeps generation local and writes the result into the page. Copy the list when you need plain text, or download it when another tool expects a file. You can choose uppercase or lowercase characters and keep or remove hyphens. Those are presentation choices. The UUID version and its bit layout do not change when you change the display format.

If you need IDs for a database import, generate a small sample first and check the receiving column type. A UUID with hyphens is 36 characters including separators. Removing hyphens makes a 32-character hexadecimal string, but it is still the same identifier. Do not remove the version and variant bits by hand.

Choosing v4 or v7

Use v4 when the identifier only needs to be opaque and very unlikely to collide. It does not contain a timestamp that applications can read. Use v7 when records are created over time and the database or log view benefits from identifiers that roughly sort in creation order. A v7 identifier is not a substitute for a separate created-at field. Clock handling, imports, and edits can still make ordering imperfect.

Both versions are specified by RFC 9562. Version 7 is useful for indexes, but measure it against the database you actually use. If an existing system requires v4, generate v4. The guide UUID v4 vs v7 compares the layouts and tradeoffs with examples.

What a UUID does not provide

Random-looking text is not automatically confidential, unguessable enough for authorization, or suitable for password storage. A UUID can identify a row, request, or event. It should not be your access control, encryption key, or session secret. Use a purpose-built secret generator and a password hashing scheme for those jobs.

Generated IDs never leave this browser. If the next step is inspecting a token that contains an ID, use the JWT Decoder. You can optionally verify the original signature with a local key there, but that still does not mean your API should trust the claims.