How to Generate a UUID in JavaScript (2026 Guide)

What a UUID is, in plain words

A UUID is a long random looking string designed to be unique without anyone having to coordinate. Two systems, two continents, two seconds apart, both generate a UUID and you can be confident the two values will not collide.

The format is 32 hexadecimal digits with four dashes thrown in for readability:

550e8400-e29b-41d4-a716-446655440000

The randomness has to be real. If two UUIDs collide, two records that should be different end up labelled the same, your database explodes, and you spend the afternoon debugging something that should not have been possible.

The problem with old code

Five years ago, generating a UUID in the browser meant pulling in uuid from npm or copy pasting a function from Stack Overflow. The function looked something like:

function uuidv4() {
  return "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx".replace(/[xy]/g, c => {
    const r = Math.random() * 16 | 0;
    const v = c == "x" ? r : (r & 0x3 | 0x8);
    return v.toString(16);
  });
}

It works. It is also wrong, because Math.random() is not cryptographically secure. The values it produces are predictable enough that, in a security context, an attacker can guess what UUIDs you will generate next.

For random IDs in non security contexts (cache keys, log correlation), the difference does not matter much. For session tokens, password reset URLs, anything where guessing the next UUID lets an attacker forge access, it matters a lot.

The right way in 2026

Every modern browser has a built in function:

crypto.randomUUID();
// "550e8400-e29b-41d4-a716-446655440000"

That single line replaces the entire uuid npm package. It uses the operating system’s cryptographic randomness, produces a properly formatted UUIDv4, and is the same function the browser itself uses internally.

The same function exists in Node.js (crypto.randomUUID()) and in Deno. The pattern is universal across modern JavaScript runtimes.

If you have an old codebase that imports the uuid package only for v4, you can delete the dependency. The download savings are tiny but the principle matters: stop importing libraries for things the platform now does for free.

When you need a UUID without writing code, the UUID generator on AldeaCode produces them in batches. It uses crypto.randomUUID() under the hood and runs in your browser, no upload, no log.

UUIDv7 and ULID: when sorted IDs matter

UUIDv4 is fully random. Two UUIDs generated a millisecond apart have nothing in common. That is great for unguessability, terrible for database performance.

When you insert a row with a random ID into a B-tree index (the data structure most databases use), the random ID lands somewhere in the middle of the tree. The tree rebalances. With millions of inserts, the rebalancing dominates.

The fix is a UUID variant that includes the current timestamp at the start. Two UUIDs generated close in time start with similar prefixes, so they land near each other in the index.

Two formats do this:

• UUIDv7 is the official UUID variant for time ordered IDs. It looks like a UUID, with a millisecond timestamp encoded in the first part. Most databases recognise it as a UUID.
• ULID is an unofficial format that uses base32 instead of hex. Sortable, more compact (26 characters instead of 36), but not a UUID by the strict spec.

For new systems in 2026, use UUIDv7 by default unless you have a specific reason for ULID. Most languages have UUIDv7 generators by now. The difference between v4 and v7 in production is real: v7 inserts in B-tree indexes are several times faster.

When to add a salt

UUIDs are unique but they are not authenticated. If your URL has a UUID in it, anyone can change one digit and load the resulting URL.

If the UUID points at a public resource, that is fine. If it points at private data (a password reset, an unlisted document), you need an extra check on the server: does this UUID belong to this user, is it still valid, has it been used.

For one off tokens, generate a UUID and store it server side with the user it belongs to and an expiry. The UUID itself does not prove anything, the database row that matches it does.

A practical 2026 routine

For any new code: use the platform crypto.randomUUID() and skip the npm package.

For database primary keys: prefer UUIDv7 (or a sequential int if your data set fits in one node). The choice matters more than people think, see UUID vs serial ID for primary keys.

For tokens that need to be unguessable: UUIDv4 backed by crypto.randomUUID(), paired with server side validation.

For sortable user-facing IDs: ULID if you control both ends, UUIDv7 if you want it to look like a normal UUID.

The UUID generator, the hash generator, and the timestamp converter on AldeaCode handle the common cases. They all run in your browser. The 2015 era of pulling a UUID library in for one function is over, the platform does the work now and does it correctly.