nanoid-dictionary

A small set of predefined character alphabets — hex, alphanumeric, lookalike-free, cookie-safe — for use with nanoid's customAlphabet.

Library
npm
v5.0.0
147stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
37/100Needs Attention
Development Activity8
Maintenance20
Community40
Maturity60
Momentum20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
66/100Good
Architecture75
Code Quality40
Innovation60
Learning Curve90

nanoid-dictionary provides a collection of ready-made character-set strings — numbers, uppercase and lowercase letters, hexadecimal, alphanumeric, lookalike-free, and cookie-safe sets — meant to be passed directly into nanoid’s customAlphabet function. Instead of hand-writing character ranges every time a project needs short unique IDs with specific constraints (URL-safe, cookie-safe, or free of visually ambiguous characters), developers import the matching constant and get a validated alphabet string.

The library ships as a zero-dependency ESM/CJS/UMD bundle with TypeScript typings, keeping the footprint small since consumers only import the sets they actually use, and pairs naturally with nanoid and the nanoid-generate CLI from the same author.

What You Get

  • Ready-made alphabet constants - numbers, lowercase, uppercase, alphanumeric, hexadecimalLowercase, and hexadecimalUppercase exported as plain strings.
  • Lookalike-free sets - nolookalikes and nolookalikesSafe remove visually ambiguous characters (0/O, l/1/I) and vowel combinations that could spell offensive words.
  • Cookie-safe sets - cookieSafe and cookieUnsafe alphabets scoped to characters permitted in HTTP cookie values per RFC 6265.
  • Multi-format build - published as CJS, ESM, and UMD bundles with bundled TypeScript declarations.

Common Use Cases

  • Short URL slugs - a web app generates lookalike-free IDs with customAlphabet(nolookalikes, 8) so support staff reading IDs aloud never confuse 0/O or l/1.
  • Cookie-based session tokens - a server builds a random cookie value from the cookieSafe character set to guarantee RFC 6265 compliance without escaping.
  • Human-readable coupon codes - a marketing tool uses nolookalikesSafe to generate promo codes that avoid accidental profanity and ambiguous characters.
  • Hex-formatted identifiers - a system generates short hex-like keys via hexadecimalLowercase for log correlation IDs.

Under The Hood

Architecture The entire package is a single flat module, src/dictionary.js, that exports plain string constants built from concatenated character ranges (e.g. alphanumeric = numbers + lowercase + uppercase). There is no runtime logic, no classes, and no state — just data. Rollup (rollup.config.mjs) compiles that one file into three output formats (CJS, ESM, UMD) declared via pkg.main/pkg.module/pkg.browser in package.json, with rollup-plugin-typescript2 emitting a .d.ts declaration file and rollup-plugin-delete clearing dist/ before each build. Because the source is a single file of constants, there is effectively nothing to break by changing the core abstraction — any change is additive (new exported sets) or a rename, both of which are low-risk and immediately visible in the generated typings.

Tech Stack The published package has zero runtime dependencies. The dev toolchain is Rollup 4 with @rollup/plugin-terser for minification, rollup-plugin-typescript2 (backed by TypeScript 5.8) purely for declaration-file generation rather than type-checked source, and rollup-plugin-delete for clean rebuilds. Output targets are declared through the standard main/module/browser/types package.json fields, so consumers on Node (CJS), bundlers (ESM), or <script> tags (UMD) all resolve a build suited to their environment.

Code Quality No test files or test runner are present anywhere in the repository, and there is no CI configuration (no .github/workflows), so correctness relies entirely on manual verification before a release. Naming is clear and consistent — each exported constant matches its README-documented name and purpose exactly. Because the module is plain JavaScript with generated (not hand-authored) type declarations, type safety is limited to what Rollup’s TypeScript plugin infers, and there is no linter or formatter configuration in the repo.

API Design The developer experience is intentionally minimal: import exactly the named character-set constants you need and pass them straight into nanoid’s customAlphabet(alphabet, size) — no configuration, no wrapper functions, no setup step. This mirrors the ergonomics of the nanoid ecosystem it extends, at the cost of any behavior beyond providing static strings; anyone needing a custom or parameterized alphabet still has to build it manually.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search