UUID v4 Generator UUID v4 生成器 


            

              
              
              
            

          


          

          

            

              
What is UUID v4?

              
UUID (Universally Unique Identifier) is a 128-bit identifier standard defined by RFC 4122. Version 4 is generated entirely from random numbers, requiring no central authority. The format is 8-4-4-4-12 hexadecimal characters, e.g., 550e8400-e29b-41d4-a716-446655440000. With 122 effective random bits, the chance of collision is negligible even at massive scale — roughly one in 5.3 × 10³⁶.

              
Why Use UUID as a Primary Key?

              
UUIDs can be generated client-side without a database round-trip, which is ideal for distributed systems, offline-first apps, and microservice architectures. Unlike auto-increment IDs, they do not leak record counts or creation order, improving security. They are the standard for session tokens, file identifiers, API resources, and distributed transaction IDs. This tool uses the browser's native crypto.randomUUID() API, guaranteeing cryptographic-grade randomness.

            

            

              
什么是 UUID v4？

              
UUID（通用唯一识别码）是 RFC 4122 定义的 128 位标识符标准。v4 版本完全基于随机数生成，无需中央注册机构。格式为 8-4-4-4-12 十六进制字符，例如 550e8400-e29b-41d4-a716-446655440000。具有 122 位有效随机位，即便大规模生成也几乎不会碰撞（概率约为 5.3×10³⁶ 分之一）。

              
UUID 作为数据库主键的优势

              
UUID 可在客户端生成，无需数据库往返，非常适合分布式系统、离线应用和微服务架构。与自增 ID 相比，UUID 不会泄露记录数量或创建顺序，安全性更高。常用于会话 Token、文件标识符、API 资源 ID 和分布式事务 ID。本工具使用浏览器原生 crypto.randomUUID() API，保证密码学级别的随机性。

            

          

        

      


      
      

        

          

            
            NanoID Generator
          


          

            

              
              
            

            

              
              
            

          


          

          

            

            

              
              
              
            

          


          

            

              
NanoID vs UUID — Why Choose NanoID?

              
NanoID generates URL-safe compact identifiers using a 64-character alphabet (A–Z, a–z, 0–9, _, -). At the default 21 characters, it offers higher entropy than UUID v4 (126 bits vs 122 bits) while being 43% shorter. This makes it ideal for URLs, API keys, and database IDs where brevity matters. This tool implements the exact NanoID algorithm using crypto.getRandomValues() with rejection sampling to eliminate modulo bias.

              
Choosing the Right Length

              
At 21 chars (default), the probability of collision reaches 1% only after generating ~2.8 trillion IDs per second for 14 years. For session tokens, 32+ characters is recommended. For short URLs or slugs, 10–12 characters usually suffices. The NanoID alphabet is URL-safe, requiring no percent-encoding.

            

            

              
NanoID 与 UUID 对比 — 为什么选择 NanoID？

              
NanoID 使用 64 字符字母表（A–Z、a–z、0–9、_、-）生成 URL 安全的紧凑标识符。默认 21 个字符提供的熵值（126 位）高于 UUID v4（122 位），同时比 UUID 短 43%。非常适合用于 URL、API Key 和数据库 ID 等需要短小精悍标识符的场景。本工具使用 crypto.getRandomValues() 实现 NanoID 算法，通过拒绝采样彻底消除模偏差。

              
如何选择合适的长度

              
默认 21 位时，碰撞概率达 1% 需要每秒生成约 2.8 万亿个 ID 并持续 14 年。Session Token 建议 32 位以上；短 URL 或 Slug 通常 10–12 位已足够；NanoID 字母表本身 URL 安全，无需额外编码。

            

          

        

      


      
      

        

          

            
            Snowflake ID Generator
            Snowflake 雪花算法 ID 生成器
          


          

            

              
              
            

            

              
              
            

          


          

          

            

            

              
              
              
            

          


          

            

              
How Snowflake IDs Work

              
Snowflake ID is a distributed ID scheme open-sourced by Twitter in 2010. It produces a 64-bit integer with a structure of: 1 sign bit (always 0) + 41-bit millisecond timestamp + 10-bit machine ID (supports 1,024 nodes) + 12-bit sequence number (4,096 IDs per millisecond per node). This makes Snowflake IDs globally unique, monotonically increasing, and highly performant.

              
Advantages for Databases

              
Unlike UUID, Snowflake IDs are pure integers, making B+ tree indexing significantly more efficient. Because the timestamp occupies the high bits, IDs are naturally time-sortable, perfect for database sharding and cursor-based pagination. They are widely used in high-traffic systems like e-commerce order IDs, social media post IDs, and distributed transaction tracking. Note: the sequence number in this browser tool uses a simulated random component.

            

            

              
雪花算法工作原理

              
Snowflake ID 是 Twitter 于 2010 年开源的分布式 ID 方案，生成 64 位整数。结构为：1 位符号位（始终为 0）+ 41 位毫秒时间戳 + 10 位机器 ID（支持 1024 台节点）+ 12 位序列号（每毫秒每节点可生成 4096 个 ID）。生成的 ID 全局唯一、单调递增、性能极高。

              
数据库场景的优势

              
与 UUID 不同，Snowflake ID 是纯整数，B+ 树索引效率显著更高。由于时间戳在高位，ID 天然按时间有序，非常适合数据库分库分表和游标分页。广泛用于电商订单号、社交媒体帖子 ID、分布式事务追踪等高流量场景。注意：本浏览器工具的序列号部分使用随机数模拟。

            

          

        

      


      
      

        

          

            
            Base64 Encoder / Decoder
            Base64 编码 / 解码
          


          
          

          

            
            
          


          

            

            

              
              
            

          


          

            

              
Base64 Encoding Explained

              
Base64 encodes binary data into 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). Every 3 bytes of input maps to 4 characters, increasing data size by ~33%. It is the standard for Data URLs (data:image/png;base64,…), JWT token headers and payloads, HTTP Basic Auth headers, email attachments (MIME), and transmitting binary over text-only protocols. This tool uses TextEncoder / TextDecoder for full UTF-8 support — correctly handling Chinese, Japanese, emoji, and all Unicode.

              
Base64 vs Base64url

              
Standard Base64 uses + and / which are not URL-safe. Base64url substitutes them with - and _, and omits padding = signs. JWT tokens use Base64url. If you need URL-safe encoding, replace + with -, / with _, and strip trailing = from the output.

            

            

              
Base64 编码原理

              
Base64 将二进制数据编码为 64 个可打印 ASCII 字符（A–Z、a–z、0–9、+、/）。每 3 字节输入映射为 4 个字符，数据量增加约 33%。广泛用于 Data URL（data:image/png;base64,…）、JWT Token 的 Header 和 Payload、HTTP Basic Auth 头、电子邮件附件（MIME）等场景。本工具使用 TextEncoder/TextDecoder 实现完整 UTF-8 支持，可正确处理中文、日文、Emoji 等所有 Unicode 内容。

              
Base64 与 Base64url 的区别

              
标准 Base64 使用 + 和 /，这两个字符在 URL 中有特殊含义，不安全。Base64url 将其替换为 - 和 _，并省略末尾的 = 填充符。JWT Token 使用的是 Base64url 编码。如需 URL 安全编码，将输出中的 + 换成 -、/ 换成 _，去掉末尾 = 即可。

            

          

        

      


      
      

        

          

            
            URL Encode / Decode
          


          
          

          

            
            
          


          

            

            

              
              
            

          


          

            

              
URL Encoding (Percent-Encoding) Explained

              
URLs may only contain a specific subset of ASCII characters. Non-ASCII characters and reserved symbols are percent-encoded: converted to UTF-8 bytes, then written as %XX for each byte. For example, a space becomes %20, and "你好" becomes %E4%BD%A0%E5%A5%BD. This tool uses encodeURIComponent, which is correct for encoding query parameter values, form data, and any string that will be embedded in a URL.

              
When to Use encodeURI vs encodeURIComponent

              
encodeURI() preserves URL structural characters (:/?#[]@) and is used when encoding a full URL. encodeURIComponent() encodes everything except alphanumerics and -_.!~*'(), making it correct for encoding individual parameter values. Always use encodeURIComponent for user-supplied strings that will appear in query strings.

            

            

              
URL 百分号编码原理

              
URL 只允许特定的 ASCII 字符。非 ASCII 字符和保留符号需要百分号编码：先转换为 UTF-8 字节序列，再用 %XX 表示每个字节。例如，空格变为 %20，"你好"变为 %E4%BD%A0%E5%A5%BD。本工具使用 encodeURIComponent，适合对 URL 查询参数值、表单数据及任何要嵌入 URL 的字符串进行编码。

              
encodeURI 与 encodeURIComponent 的区别

              
encodeURI() 保留 URL 结构字符（:/?#[]@），用于对完整 URL 编码。encodeURIComponent() 对字母数字和 -_.!~*'() 以外的所有字符编码，适合对参数值编码。对于用户输入的字符串，始终应使用 encodeURIComponent 嵌入查询字符串。

            

          

        

      


      
      

        

          

            
            Hash Calculator — MD5 / SHA
            哈希值计算器 — MD5 / SHA
          


          
          

          

            

            

            

            

          


          
          

          

            

              
Hash Algorithm Security Comparison

              
MD5 (128-bit / 32 hex chars) — Collision vulnerabilities proven in 2004. Not for security purposes; still useful for checksums and file integrity verification. SHA-1 (160-bit / 40 hex chars) — Practically broken by Google's SHAttered attack (2017); deprecated by all modern browsers and CAs. SHA-256 (256-bit / 64 hex chars) — The current security gold standard, used in TLS certificates, Bitcoin, and code signing. SHA-512 (512-bit / 128 hex chars) — Faster than SHA-256 on 64-bit systems; provides a larger security margin.

              
⚠️ Never Use These for Password Storage

              
General-purpose hash functions are designed to be fast, making them vulnerable to brute-force and rainbow table attacks. For storing passwords, always use purpose-built slow hash functions: bcrypt, scrypt, or Argon2 (the Argon2id variant is the current recommendation from OWASP).

            

            

              
哈希算法安全性对比

              
MD5（128 位 / 32 个十六进制字符） — 2004 年被证明存在碰撞漏洞，不应用于安全目的，但仍可用于校验和与文件完整性验证。SHA-1（160 位 / 40 字符） — 已被 Google 的 SHAttered 攻击（2017 年）实际破解，所有现代浏览器和 CA 均已弃用。SHA-256（256 位 / 64 字符） — 当前安全黄金标准，用于 TLS 证书、比特币、代码签名。SHA-512（512 位 / 128 字符） — 在 64 位系统上比 SHA-256 更快，安全边际更大。

              
⚠️ 绝不可将以上算法用于密码存储

              
通用哈希函数设计为高速计算，容易被暴力破解和彩虹表攻击。存储密码必须使用专为此设计的慢哈希算法：bcrypt、scrypt 或 Argon2（OWASP 当前推荐 Argon2id 变体）。

            

          

        

      


      
      

        

          

            
            Secure Password Generator
            安全随机密码生成器
          


          

            

              

                
                
              

              

                
                
              

            

            

              
              
              
              
            

          


          

          

            

            

              
              
              
            

          


          

            

              
What Makes a Password Strong?

              
Password strength is measured in entropy: bits = length × log₂(charset_size). With this tool's defaults (16 characters, 95-char set of uppercase + lowercase + digits + symbols), entropy is ~105 bits — considered unbreakable with current technology. Even at 10¹² guesses/second, exhausting all possibilities would take longer than the age of the universe. This tool uses crypto.getRandomValues() (a CSPRNG) and guarantees at least one character from each selected set via Fisher-Yates shuffle — no bias, no predictability.

              
Security Notes

              
All generation runs entirely in your browser — passwords never reach any server. We recommend storing the results in a trusted password manager such as Bitwarden (open source), 1Password, or KeePass. Per NIST SP 800-63B, length matters far more than forced symbol complexity, which is why a 20-character random phrase or password beats a short "complex" one every time.

            

            

              
强密码的标准是什么？

              
密码强度用熵值衡量：熵 = 长度 × log₂(字符集大小)。使用本工具默认设置（16 字符，大小写+数字+符号共 95 字符集），熵值约 105 位——以当前技术几乎无法破解。即使每秒尝试 10¹² 次，穷举所有可能性也需要比宇宙年龄更长的时间。本工具使用密码学安全伪随机数生成器（CSPRNG）crypto.getRandomValues()，并通过 Fisher-Yates 洗牌保证每个选中字符集至少出现一次，无偏差、无可预测性。

              
安全使用建议

              
所有生成过程完全在浏览器本地运行，密码不会发送到任何服务器。建议将生成的密码存入可信密码管理器，如 Bitwarden（开源）、1Password 或 KeePass。根据 NIST SP 800-63B 标准，密码长度比强制符号复杂度重要得多——一个 20 字符随机密码远胜一个短而"复杂"的密码。

            

          

        

      


      
      

        

          

            
            QR Code Generator
            二维码生成器
          


          

            

              
              
              
            


            

              

              

                
                
              

            

          


          

            

              
QR Code Fundamentals

              
QR Code (Quick Response Code) was invented by Denso Wave in Japan in 1994. It's a 2D matrix barcode that stores information in both horizontal and vertical directions, capable of holding up to ~7,089 numeric or ~4,296 alphanumeric characters. Four error correction levels (L / M / Q / H) allow 7–30% of the code to be damaged and still remain readable, which is why you can overlay logos on QR codes. Versions 1–40 define the grid size (21×21 to 177×177 modules).

              
Common Use Cases

              
QR codes are used for URL sharing in print media and business cards, mobile payments, event ticketing, product traceability, Wi-Fi credential sharing (format: WIFI:S:MyNetwork;T:WPA;P:MyPassword;;), vCard contact sharing, app download links, and two-factor authentication (TOTP). This tool uses error correction level M, offering a good balance between data density and reliability.

            

            

              
二维码基础知识

              
QR Code（快速响应码）由日本电装公司（Denso Wave）于 1994 年发明，可在水平和垂直两个方向存储信息，最多可容纳约 7,089 个数字或 4,296 个字母数字字符。四个纠错级别（L/M/Q/H）允许 7%–30% 的码面受损后仍可读取，这也是二维码可以叠加 Logo 的原因。版本 1–40 决定网格尺寸（21×21 到 177×177 模块）。

              
常见应用场景

              
二维码广泛用于：印刷物料和名片上的 URL 分享、移动支付、活动签到、产品溯源、Wi-Fi 密码共享（格式：WIFI:S:网络名;T:WPA;P:密码;;）、vCard 名片分享、应用下载链接和双因素认证（TOTP）。本工具使用纠错级别 M，在数据密度与可靠性之间取得良好平衡。