uuid vs nanoid vs shortid vs randomstring
Generating Unique Identifiers in JavaScript Applications
uuidnanoidshortidrandomstringSimilar Packages:
Generating Unique Identifiers in JavaScript Applications

nanoid, randomstring, shortid, and uuid are all npm packages used to generate unique identifiers in JavaScript applications, but they differ significantly in design goals, collision resistance, output format, and suitability for modern frontend environments. uuid is the most mature and standards-compliant, producing universally unique identifiers (UUIDs) per RFC specifications. nanoid focuses on compact, URL-safe IDs with minimal size and high performance using cryptographically strong randomness. randomstring offers flexible string generation with extensive customization options but isn’t specifically designed for unique ID use cases. shortid was created to produce short, non-sequential IDs but has known limitations in uniqueness guarantees and is no longer maintained.

Npm Package Weekly Downloads Trend
3 Years
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
uuid179,531,27615,15666.7 kB22 months agoMIT
nanoid71,672,23726,33412.3 kB32 months agoMIT
shortid879,4055,72621.7 kB1610 months agoMIT
randomstring699,19552116.6 kB210 months agoMIT

Generating Unique IDs in JavaScript: nanoid vs randomstring vs shortid vs uuid

When building modern web apps, you’ll often need to generate unique identifiers — for temporary DOM elements, client-side entity keys, cache entries, or sync tokens. But not all ID generators are created equal. Let’s break down how nanoid, randomstring, shortid, and uuid actually behave in real-world frontend scenarios.

🔢 What Kind of ID Do You Really Need?

Before comparing libraries, ask: What problem am I solving?

  • Globally unique across systems? → Use uuid.
  • Short, fast, client-only IDs? → Use nanoid.
  • Custom-formatted random text (not necessarily unique)? → Consider randomstring.
  • Legacy compatibility? → Avoid shortid; migrate away.

Each package makes different trade-offs between size, safety, standardization, and flexibility.

🧪 Collision Resistance: How Safe Is "Unique"?

uuid generates RFC-compliant identifiers. Version 4 (random-based) uses 122 bits of entropy — so the chance of collision is astronomically low, even at billions of IDs per second. This is why databases like PostgreSQL natively support UUIDs.

// uuid v4 example
import { v4 as uuidv4 } from 'uuid';
const id = uuidv4(); // '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'

nanoid uses a larger alphabet (A-Za-z0-9_-) and defaults to 21 characters, giving ~126 bits of entropy — comparable to UUID v4 but in a shorter string. It leverages the browser’s crypto.getRandomValues() for true randomness, making it safe for client-side use.

// nanoid example
import { nanoid } from 'nanoid';
const id = nanoid(); // 'V1StGXR8_Z5jdHi6B-myT'

randomstring doesn’t guarantee uniqueness. It’s a general-purpose string generator. If you call it twice with the same settings, you might get duplicates — and there’s no built-in mechanism to prevent that.

// randomstring — not for unique IDs!
import randomstring from 'randomstring';
const str = randomstring.generate(10); // 'aB3xK9mQ2p' — could repeat

shortid uses only 7–14 characters with a small alphabet, resulting in very limited entropy. Worse, it relied on a shared internal counter that resets on app restart — causing predictable sequences and high collision risk in serverless or multi-tab environments. It is deprecated and should not be used in new code.

📏 Output Format and Size Matter

  • uuid: Always 36 chars (with hyphens). Hard to shorten safely.
  • nanoid: Default 21 chars, no special characters, URL-safe.
  • randomstring: Fully configurable — but defaults aren’t optimized for IDs.
  • shortid: ~7–10 chars, but unsafe.

If you’re embedding IDs in URLs or class names, nanoid’s compact, clean output wins. For database keys or API payloads where standards matter, uuid’s structure is an advantage.

🌐 Browser Compatibility and Security

All four work in browsers, but security differs:

  • nanoid and uuid both use cryptographically secure random sources in modern browsers (crypto.getRandomValues).
  • randomstring falls back to Math.random() unless you explicitly enable secure mode — which many developers forget.
  • shortid used insecure randomness in early versions and never updated its approach.

Never trust Math.random() for anything requiring uniqueness or unpredictability — it’s deterministic and easily guessable.

⚙️ Customization vs Simplicity

Need a 12-character alphanumeric ID without vowels (to avoid accidental words)? randomstring can do that:

randomstring.generate({
  length: 12,
  charset: 'abcdefghjkmnpqrstuvwxyz23456789'
});

But if you just need a safe, short ID with zero config, nanoid is simpler:

nanoid(12); // 'K7cL9pXqR2mN'

uuid offers versioned generation (e.g., time-based v1 or lexicographically sortable v7), useful for databases, but adds complexity if you don’t need it.

🛑 The Shortid Situation

shortid was popular around 2016–2018 for its brevity, but its author officially deprecated it in 2019, recommending nanoid as a replacement. Known issues include:

  • Collisions after ~16k IDs in a single process
  • Non-cryptographic randomness
  • No updates for modern JavaScript environments

If you see it in a codebase, treat it as technical debt.

✅ Practical Recommendations

Use CaseBest Choice
Client-side React keys, temp IDsnanoid
Database primary keys, API identifiersuuid (v4 or v7)
Test data, passwords, mock contentrandomstring
Any new project needing short IDsNot shortid — use nanoid

💡 Pro Tip: Avoid Reinventing the Wheel

Don’t roll your own ID generator using Date.now() + Math.random(). Even subtle bugs can cause hard-to-debug duplication issues in production. Stick to battle-tested libraries that understand entropy, randomness, and collision math.

In summary: Use nanoid for short client IDs, uuid for system-wide uniqueness, randomstring for non-unique random text, and never shortid in new code.

How to Choose: uuid vs nanoid vs shortid vs randomstring
  • uuid:

    Choose uuid when you need standards-compliant, universally unique identifiers — especially if interoperability with backend systems, databases, or external APIs is required. It supports multiple UUID versions (v1, v4, v7), with v4 being the most common for random IDs. While slightly larger than nanoid outputs (36 characters vs ~21), its predictability, widespread adoption, and robust collision resistance make it the safe default for most production systems.

  • nanoid:

    Choose nanoid when you need very short, URL-safe identifiers with strong uniqueness guarantees and minimal bundle impact. It’s ideal for client-side ID generation in SPAs, cache keys, or temporary DOM element IDs where size and speed matter. Its use of cryptographic randomness (via Web Crypto API in browsers) ensures low collision risk even at scale, and it avoids problematic characters like hyphens or underscores by default.

  • shortid:

    Do not choose shortid for new projects. It is deprecated and no longer maintained, with documented issues around ID collisions under moderate load due to its limited entropy and reliance on process-specific counters. If you’re maintaining legacy code that uses it, plan a migration to nanoid or uuid.

  • randomstring:

    Choose randomstring when your primary need is customizable random strings — not necessarily globally unique IDs. It shines in scenarios like password generation, test fixtures, or placeholder content where you control length, character sets, and patterns. However, avoid it for distributed ID generation since it lacks built-in collision resistance strategies and isn’t optimized for uniqueness.

README for uuid

uuid CI Browser

For the creation of RFC9562 (formerly RFC4122) UUIDs

[!NOTE]

Starting with uuid@12 CommonJS is no longer supported. See implications and motivation for details.

Quickstart

1. Install

npm install uuid

2. Create a UUID

import { v4 as uuidv4 } from 'uuid';

uuidv4(); // ⇨ '9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d'

For timestamp UUIDs, namespace UUIDs, and other options read on ...

API Summary

uuid.NILThe nil UUID string (all zeros)New in uuid@8.3
uuid.MAXThe max UUID string (all ones)New in uuid@9.1
uuid.parse()Convert UUID string to array of bytesNew in uuid@8.3
uuid.stringify()Convert array of bytes to UUID stringNew in uuid@8.3
uuid.v1()Create a version 1 (timestamp) UUID
uuid.v1ToV6()Create a version 6 UUID from a version 1 UUIDNew in uuid@10
uuid.v3()Create a version 3 (namespace w/ MD5) UUID
uuid.v4()Create a version 4 (random) UUID
uuid.v5()Create a version 5 (namespace w/ SHA-1) UUID
uuid.v6()Create a version 6 (timestamp, reordered) UUIDNew in uuid@10
uuid.v6ToV1()Create a version 1 UUID from a version 6 UUIDNew in uuid@10
uuid.v7()Create a version 7 (Unix Epoch time-based) UUIDNew in uuid@10
uuid.v8()"Intentionally left blank"
uuid.validate()Test a string to see if it is a valid UUIDNew in uuid@8.3
uuid.version()Detect RFC version of a UUIDNew in uuid@8.3

API

uuid.NIL

The nil UUID string (all zeros).

Example:

import { NIL as NIL_UUID } from 'uuid';

NIL_UUID; // ⇨ '00000000-0000-0000-0000-000000000000'

uuid.MAX

The max UUID string (all ones).

Example:

import { MAX as MAX_UUID } from 'uuid';

MAX_UUID; // ⇨ 'ffffffff-ffff-ffff-ffff-ffffffffffff'

uuid.parse(str)

Convert UUID string to array of bytes

strA valid UUID String
returnsUint8Array[16]
throwsTypeError if str is not a valid UUID

[!NOTE] Ordering of values in the byte arrays used by parse() and stringify() follows the left ↠ right order of hex-pairs in UUID strings. As shown in the example below.

Example:

import { parse as uuidParse } from 'uuid';

// Parse a UUID
uuidParse('6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b'); // ⇨
// Uint8Array(16) [
//   110, 192, 189, 127,  17,
//   192,  67, 218, 151,  94,
//    42, 138, 217, 235, 174,
//    11
// ]

uuid.stringify(arr[, offset])

Convert array of bytes to UUID string

arrArray-like collection of 16 values (starting from offset) between 0-255.
[offset = 0]Number Starting index in the Array
returnsString
throwsTypeError if a valid UUID string cannot be generated

[!NOTE] Ordering of values in the byte arrays used by parse() and stringify() follows the left ↠ right order of hex-pairs in UUID strings. As shown in the example below.

Example:

import { stringify as uuidStringify } from 'uuid';

const uuidBytes = Uint8Array.of(
  0x6e,
  0xc0,
  0xbd,
  0x7f,
  0x11,
  0xc0,
  0x43,
  0xda,
  0x97,
  0x5e,
  0x2a,
  0x8a,
  0xd9,
  0xeb,
  0xae,
  0x0b
);

uuidStringify(uuidBytes); // ⇨ '6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b'

uuid.v1([options[, buffer[, offset]]])

Create an RFC version 1 (timestamp) UUID

[options]Object with one or more of the following properties:
[options.node = (random) ]RFC "node" field as an Array[6] of byte values (per 4.1.6)
[options.clockseq = (random)]RFC "clock sequence" as a Number between 0 - 0x3fff
[options.msecs = (current time)]RFC "timestamp" field (Number of milliseconds, unix epoch)
[options.nsecs = 0]RFC "timestamp" field (Number of nanoseconds to add to msecs, should be 0-10,000)
[options.random = (random)]Array of 16 random bytes (0-255) used to generate other fields, above
[options.rng]Alternative to options.random, a Function that returns an Array of 16 random bytes (0-255)
[buffer]Uint8Array or Uint8Array subtype (e.g. Node.js Buffer). If provided, binary UUID is written into the array, starting at offset
[offset = 0]Number Index to start writing UUID bytes in buffer
returnsUUID String if no buffer is specified, otherwise returns buffer
throwsError if more than 10M UUIDs/sec are requested

[!NOTE] The default node id (the last 12 digits in the UUID) is generated once, randomly, on process startup, and then remains unchanged for the duration of the process.

[!NOTE] options.random and options.rng are only meaningful on the very first call to v1(), where they may be passed to initialize the internal node and clockseq fields.

Example:

import { v1 as uuidv1 } from 'uuid';

uuidv1(); // ⇨ '2c5ea4c0-4067-11e9-9b5d-ab8dfbbd4bed'

Example using options:

import { v1 as uuidv1 } from 'uuid';

const options = {
  node: Uint8Array.of(0x01, 0x23, 0x45, 0x67, 0x89, 0xab),
  clockseq: 0x1234,
  msecs: new Date('2011-11-01').getTime(),
  nsecs: 5678,
};
uuidv1(options); // ⇨ '710b962e-041c-11e1-9234-0123456789ab'

uuid.v1ToV6(uuid)

Convert a UUID from version 1 to version 6

import { v1ToV6 } from 'uuid';

v1ToV6('92f62d9e-22c4-11ef-97e9-325096b39f47'); // ⇨ '1ef22c49-2f62-6d9e-97e9-325096b39f47'

uuid.v3(name, namespace[, buffer[, offset]])

Create an RFC version 3 (namespace w/ MD5) UUID

API is identical to v5(), but uses "v3" instead.

[!IMPORTANT] Per the RFC, "If backward compatibility is not an issue, SHA-1 [Version 5] is preferred."

uuid.v4([options[, buffer[, offset]]])

Create an RFC version 4 (random) UUID

[options]Object with one or more of the following properties:
[options.random]Array of 16 random bytes (0-255)
[options.rng]Alternative to options.random, a Function that returns an Array of 16 random bytes (0-255)
[buffer]Uint8Array or Uint8Array subtype (e.g. Node.js Buffer). If provided, binary UUID is written into the array, starting at offset
[offset = 0]Number Index to start writing UUID bytes in buffer
returnsUUID String if no buffer is specified, otherwise returns buffer

Example:

import { v4 as uuidv4 } from 'uuid';

uuidv4(); // ⇨ '1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed'

Example using predefined random values:

import { v4 as uuidv4 } from 'uuid';

const v4options = {
  random: Uint8Array.of(
    0x10,
    0x91,
    0x56,
    0xbe,
    0xc4,
    0xfb,
    0xc1,
    0xea,
    0x71,
    0xb4,
    0xef,
    0xe1,
    0x67,
    0x1c,
    0x58,
    0x36
  ),
};
uuidv4(v4options); // ⇨ '109156be-c4fb-41ea-b1b4-efe1671c5836'

uuid.v5(name, namespace[, buffer[, offset]])

Create an RFC version 5 (namespace w/ SHA-1) UUID

nameString | Array
namespaceString | Array[16] Namespace UUID
[buffer]Uint8Array or Uint8Array subtype (e.g. Node.js Buffer). If provided, binary UUID is written into the array, starting at offset
[offset = 0]Number Index to start writing UUID bytes in buffer
returnsUUID String if no buffer is specified, otherwise returns buffer

[!NOTE] The RFC DNS and URL namespaces are available as v5.DNS and v5.URL.

Example with custom namespace:

import { v5 as uuidv5 } from 'uuid';

// Define a custom namespace.  Readers, create your own using something like
// https://www.uuidgenerator.net/
const MY_NAMESPACE = '1b671a64-40d5-491e-99b0-da01ff1f3341';

uuidv5('Hello, World!', MY_NAMESPACE); // ⇨ '630eb68f-e0fa-5ecc-887a-7c7a62614681'

Example with RFC URL namespace:

import { v5 as uuidv5 } from 'uuid';

uuidv5('https://www.w3.org/', uuidv5.URL); // ⇨ 'c106a26a-21bb-5538-8bf2-57095d1976c1'

uuid.v6([options[, buffer[, offset]]])

Create an RFC version 6 (timestamp, reordered) UUID

This method takes the same arguments as uuid.v1().

import { v6 as uuidv6 } from 'uuid';

uuidv6(); // ⇨ '1e940672-c5ea-64c1-9bdd-2b0d7b3dcb6d'

Example using options:

import { v6 as uuidv6 } from 'uuid';

const options = {
  node: [0x01, 0x23, 0x45, 0x67, 0x89, 0xab],
  clockseq: 0x1234,
  msecs: new Date('2011-11-01').getTime(),
  nsecs: 5678,
};
uuidv6(options); // ⇨ '1e1041c7-10b9-662e-9234-0123456789ab'

uuid.v6ToV1(uuid)

Convert a UUID from version 6 to version 1

import { v6ToV1 } from 'uuid';

v6ToV1('1ef22c49-2f62-6d9e-97e9-325096b39f47'); // ⇨ '92f62d9e-22c4-11ef-97e9-325096b39f47'

uuid.v7([options[, buffer[, offset]]])

Create an RFC version 7 (random) UUID

[options]Object with one or more of the following properties:
[options.msecs = (current time)]RFC "timestamp" field (Number of milliseconds, unix epoch)
[options.random = (random)]Array of 16 random bytes (0-255) used to generate other fields, above
[options.rng]Alternative to options.random, a Function that returns an Array of 16 random bytes (0-255)
[options.seq = (random)]32-bit sequence Number between 0 - 0xffffffff. This may be provided to help ensure uniqueness for UUIDs generated within the same millisecond time interval. Default = random value.
[buffer]Uint8Array or Uint8Array subtype (e.g. Node.js Buffer). If provided, binary UUID is written into the array, starting at offset
[offset = 0]Number Index to start writing UUID bytes in buffer
returnsUUID String if no buffer is specified, otherwise returns buffer

Example:

import { v7 as uuidv7 } from 'uuid';

uuidv7(); // ⇨ '01695553-c90c-745a-b76f-770d7b3dcb6d'

uuid.v8()

"Intentionally left blank"

[!NOTE] Version 8 (experimental) UUIDs are "for experimental or vendor-specific use cases". The RFC does not define a creation algorithm for them, which is why this package does not offer a v8() method. The validate() and version() methods do work with such UUIDs, however.

uuid.validate(str)

Test a string to see if it is a valid UUID

strString to validate
returnstrue if string is a valid UUID, false otherwise

Example:

import { validate as uuidValidate } from 'uuid';

uuidValidate('not a UUID'); // ⇨ false
uuidValidate('6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b'); // ⇨ true

Using validate and version together it is possible to do per-version validation, e.g. validate for only v4 UUIds.

import { version as uuidVersion } from 'uuid';
import { validate as uuidValidate } from 'uuid';

function uuidValidateV4(uuid) {
  return uuidValidate(uuid) && uuidVersion(uuid) === 4;
}

const v1Uuid = 'd9428888-122b-11e1-b85c-61cd3cbb3210';
const v4Uuid = '109156be-c4fb-41ea-b1b4-efe1671c5836';

uuidValidateV4(v4Uuid); // ⇨ true
uuidValidateV4(v1Uuid); // ⇨ false

uuid.version(str)

Detect RFC version of a UUID

strA valid UUID String
returnsNumber The RFC version of the UUID
throwsTypeError if str is not a valid UUID

Example:

import { version as uuidVersion } from 'uuid';

uuidVersion('45637ec4-c85f-11ea-87d0-0242ac130003'); // ⇨ 1
uuidVersion('6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b'); // ⇨ 4

[!NOTE] This method returns 0 for the NIL UUID, and 15 for the MAX UUID.

Command Line

UUIDs can be generated from the command line using uuid.

$ npx uuid
ddeb27fb-d9a0-4624-be4d-4615062daed4

The default is to generate version 4 UUIDS, however the other versions are supported. Type uuid --help for details:

$ npx uuid --help

Usage:
  uuid
  uuid v1
  uuid v3 <name> <namespace uuid>
  uuid v4
  uuid v5 <name> <namespace uuid>
  uuid v7
  uuid --help

Note: <namespace uuid> may be "URL" or "DNS" to use the corresponding UUIDs
defined by RFC9562

options Handling for Timestamp UUIDs

Prior to uuid@11, it was possible for options state to interfere with the internal state used to ensure uniqueness of timestamp-based UUIDs (the v1(), v6(), and v7() methods). Starting with uuid@11, this issue has been addressed by using the presence of the options argument as a flag to select between two possible behaviors:

  • Without options: Internal state is utilized to improve UUID uniqueness.
  • With options: Internal state is NOT used and, instead, appropriate defaults are applied as needed.

Support

Browsers: uuid builds are tested against the latest version of desktop Chrome, Safari, Firefox, and Edge. Mobile versions of these same browsers are expected to work but aren't currently tested.

Node: uuid builds are tested against node (LTS releases), plus one prior. E.g. At the time of this writing node@20 is the "maintenance" release and node@24 is the "current" release, so uuid supports node@18-node@24.

Typescript: TS versions released within the past two years are supported. source

Known issues

"getRandomValues() not supported"

This error occurs in environments where the standard crypto.getRandomValues() API is not supported. This issue can be resolved by adding an appropriate polyfill:

React Native / Expo

  1. Install react-native-get-random-values
  2. Import it before uuid. Since uuid might also appear as a transitive dependency of some other imports it's safest to just import react-native-get-random-values as the very first thing in your entry point:
import 'react-native-get-random-values';
import { v4 as uuidv4 } from 'uuid';

Markdown generated from README_js.md by