Nano ID 生成工具
在浏览器中批量生成 URL 安全的简短唯一 ID。可自由指定字符集（默认、字母数字、小写、大写、数字、十六进制）和长度，非常适合需要比 UUID 更短的 ID 的场景。
ID 格式对比
| 格式 | 长度 | 字符集大小 | 能否按生成顺序排序 | 说明 |
|---|---|---|---|---|
| Nano ID | 默认21个字符（可指定1〜64个字符） | 64个字符 | 不能（完全随机） | 仅由 URL 安全字符组成的短随机 ID，可自由更改字符集和长度。 |
| UUID v4 | 36个字符（含4个连字符） | 16个字符（十六进制） | 不能（完全随机） | 由 RFC 9562 标准化的128位标识符，以连字符分隔的十六进制表示法为标准格式。 |
| ULID | 26个字符 | 32个字符（Base32） | 能（前10个字符为时间戳） | 开头带有毫秒级时间戳，因此可以按字符串顺序排列生成顺序。 |
使用技巧
- Nano ID 使用基于 Web Crypto API 的密码学安全随机数生成，且全部在浏览器内处理，不会发送到 toolbase.cc 的服务器。
- 默认的64字符字母表（
A-Za-z0-9_-）不含符号或空格，可以直接安全地用作URL 路径或文件名。 - 将字符集限定为"仅数字"或"十六进制"，可以生成符合现有系统 ID 格式（例如订单编号仅为数字）的 ID。
- 长度越短，碰撞概率越高。发行量大的系统建议保持默认的21个字符左右，少量测试数据用8〜10个字符左右也可能足够。
- 增加生成数量后使用"全部复制"，便于批量创建测试数据或种子数据。
常见问题
如果想直接将短 ID 用于 URL 或文件名，Nano ID 更合适。如果需要 RFC 标准化的格式，或者重视与其他系统的互操作性，UUID（尤其是 v4）是更稳妥的选择。
在默认的21个字符、64种字符的设置下，具有相当于126位的随机性，实际使用中的碰撞概率几乎可以忽略。计算得出，碰撞概率达到50%所需的生成数量约为1.09×10¹⁹个。
可以，但和 UUID v4 一样是完全随机的，因此插入 B-Tree 索引的效率不如 AUTO_INCREMENT。如果需要按插入顺序排序，建议考虑使用开头带时间戳的 ULID 等方案。
是的。即使长度相同，字符集大小（字母表大小）越小，随机性越低（抵御碰撞的能力也越弱）。若要用仅数字（10种字符）达到与64种字符字母表相同的安全性，需要更长的字符数。
闲话 ― 为什么 Nano ID 能比 UUID 更短
Nano ID 是 PostCSS 的开发者 Andrey Sitnik 于2017年发布的 JavaScript ID 生成库。它没有依赖项，代码量仅有几百字节，却使用密码学安全的随机数，这种设计获得了广泛认可，如今在 npm 上每周下载量达数千万次，成为常用库之一。
ID 的长度取决于所用字符集的大小。UUID 仅使用十六进制（16种字符）来表示128位，因此需要36个字符；而 Nano ID 使用64种字符，仅用21个字符就能表示相当程度的随机性（默认设置下为126位）。这是因为每个字符所携带的信息量（log₂64＝6位）大于十六进制（log₂16＝4位），这正是缩短长度的原因。
默认设置（21个字符、64种字符）所具有的126位随机性，与 UUID v4 的122位几乎相当。根据生日问题的近似公式计算，碰撞概率达到50%所需的生成数量约为1.09×10¹⁹个，实际使用中几乎无需担心。