shortid generator

ShortID is a JavaScript library that generates short, URL-friendly, non-sequential unique identifiers. Originally created by Dylan Greene and published on npm, ShortID gained widespread adoption in the Node.js ecosystem during the mid-2010s as a lightweight alternative to UUIDs for generating concise, human-readable identifiers. The library produces IDs between 7 and 14 characters long using an alphabet of URL-safe characters, and it was widely used for database keys, URL slugs, and session tokens. However, ShortID is now officially deprecated by its maintainer, and its npm page and repository explicitly recommend migrating to Nano ID as a superior replacement. Understanding why ShortID fell out of favor and what to use instead is important for any developer maintaining legacy codebases that still depend on it.

ShortID was designed in an era when the primary concern was generating IDs that were shorter and more human-friendly than UUIDs. It succeeded at that goal, but subsequent security analysis revealed fundamental weaknesses in its approach to randomness and its vulnerability to sequential prediction. The library uses a non-cryptographic random number generator by default, which means that an attacker who can observe a sequence of generated IDs may be able to predict future values. Additionally, the shuffled alphabet mechanism that ShortID uses to obscure sequential patterns is not a robust security measure and can be reverse-engineered. These shortcomings are significant in modern web applications where identifier predictability can lead to enumeration attacks, unauthorized data access, and other security vulnerabilities.

How ShortID Works

ShortID generates identifiers by combining several sources of low-entropy data and encoding the result using a shuffled character alphabet. The generation process begins with a seed value derived from a combination of the current timestamp, a process-level counter, and the system's Math.random() function. These inputs are combined to produce a numeric value, which is then encoded into a string using a 64-character alphabet.

The alphabet used by ShortID consists of the characters 0-9, a-z, A-Z, and the underscore and hyphen characters, making the output URL-safe without encoding. However, the key weakness lies in the randomness source. Math.random() in JavaScript is not cryptographically secure. It uses a pseudo-random number generator (typically xorshift128+ in modern engines) that is designed for speed rather than unpredictability. An attacker with knowledge of the engine state or a sufficient number of observed outputs can reconstruct the internal state and predict future random values.

To obscure the sequential nature of its output, ShortID applies an alphabet shuffle. The default 64-character alphabet is rearranged using a seed value, so that consecutive numeric values map to visually unrelated characters. This provides an appearance of randomness but is fundamentally a substitution cipher, not a source of entropy. The shuffle is deterministic given the seed, and once the seed is known (or guessed), the entire mapping is compromised.

ShortID also includes a worker ID mechanism intended for use in clustered environments. Each worker can be assigned a numeric ID (0-15) that is incorporated into generated values to reduce the chance of collisions across processes. However, this mechanism provides only 4 bits of differentiation and is not sufficient for truly distributed generation at scale.

The variable-length output (7 to 14 characters) is another characteristic that can cause issues in practice. Database schemas, API contracts, and validation logic often assume fixed-length identifiers, and the variable length of ShortID values can introduce edge cases and compatibility problems that fixed-length alternatives avoid.

Use Cases

Legacy web applications requiring migration. The most common scenario involving ShortID today is maintaining or migrating an existing application that already uses it. Many Node.js applications built between 2014 and 2019 adopted ShortID for generating user-facing identifiers, URL slugs, or database keys. These applications may have millions of existing records keyed by ShortID values. In these cases, the practical path forward is to continue accepting existing ShortID values while generating all new identifiers using a modern alternative like Nano ID. A dual-read strategy, where the application recognizes both old ShortID format values and new Nano ID values, allows for a gradual migration without data loss or downtime.

Low-security internal tooling. In strictly internal tools where identifiers are never exposed to untrusted users and security is not a concern, ShortID's simplicity may have been acceptable. Examples include internal build identifiers, development environment labels, or temporary file naming. Even in these contexts, the migration cost to Nano ID is minimal (the API is similarly simple), so there is little reason to continue using ShortID for new projects.

Educational examples of ID generation pitfalls. ShortID serves as a useful case study in software engineering for illustrating why cryptographic randomness matters in identifier generation. The library's vulnerabilities demonstrate how non-cryptographic PRNGs, alphabet shuffling as a security mechanism, and insufficient entropy can create real-world attack vectors. Understanding these pitfalls helps developers evaluate newer identifier libraries more critically.

Comparison with Alternatives

Nano ID is the direct successor recommended by ShortID's own maintainer. Nano ID addresses every significant weakness of ShortID while providing a similar developer experience. It uses the Web Crypto API (crypto.getRandomValues) for cryptographically secure randomness, produces fixed-length identifiers by default (21 characters with the default alphabet), and offers a customizable alphabet and length to suit specific requirements. Nano ID is also significantly smaller in bundle size (approximately 130 bytes when minified and gzipped) compared to ShortID, making it a better choice for browser-based applications where payload size matters. The API migration is straightforward: where ShortID uses shortid.generate(), Nano ID uses nanoid(), and both return a URL-safe string. For virtually every use case where ShortID was previously employed, Nano ID is a direct, superior replacement.

CUID2 takes a different approach that is worth considering for applications that need stronger security properties beyond what random IDs alone provide. CUID2 is the successor to the original CUID library and uses a cryptographic hash function (SHA-256) combined with entropy from multiple sources including the timestamp, a counter, random data, and host fingerprinting. The result is an identifier that is not only collision-resistant but also resistant to reverse engineering. An attacker who obtains a CUID2 value cannot extract the timestamp, machine identity, or any other input that went into its generation. This makes CUID2 particularly suitable for user-facing identifiers in security-sensitive applications, such as API keys, session tokens, or public-facing resource URLs. CUID2 identifiers are longer than Nano ID defaults (24 characters), but the additional security properties may justify the extra length depending on the application's threat model.

Compared to both modern alternatives, ShortID's core deficiencies are clear: non-cryptographic randomness makes its output predictable, its variable length complicates schema design, its alphabet shuffling provides only superficial obfuscation, and its maintenance status means it will not receive security patches or compatibility updates for newer JavaScript runtimes. Any project currently using ShortID should prioritize migration. For simple, fast, cryptographically secure random identifiers, migrate to Nano ID. For applications where identifier security is critical and you need protection against information leakage through IDs, consider CUID2. In either case, the migration effort is minimal compared to the security and reliability improvements gained.