UUID / NanoID Generator

The UUID / NanoID Generator is a small utility for creating unique identifiers that are safe to use in most databases, APIs, and distributed systems. It supports RFC 4122 UUIDs as well as shorter, URL-friendly NanoIDs — all generated client-side so nothing leaves your browser.

• Choose the ID type: UUID v4 or NanoID.
• Optionally adjust NanoID length or alphabet if the tool allows.
• Generate a new ID and copy it into your code, config, or tests.
• For tests, generate a fixed ID once and reuse it to keep snapshots stable.

Both UUIDs and NanoIDs are suitable for many common tasks, but they have slightly different trade-offs:

• UUID v4: widely supported across languages and databases; fixed 36-character string with hyphens.
• NanoID: shorter, URL-safe, and visually cleaner; good for URLs, slugs, and user-facing IDs if you're okay with a custom format.
• For existing systems or standards, UUID is usually the safer default; for new internal tools or front-end-heavy apps, NanoID is often more ergonomic.

Both UUIDs and NanoIDs can be used in URLs and JSON APIs, but NanoID has a few practical advantages:

• NanoIDs are typically shorter and do not include hyphens, which can make URLs more compact.
• Default NanoID alphabets are URL-safe, so you don't have to worry about escaping.
• UUIDs are more recognized by tooling (validators, linters, etc.) and may integrate better with existing libraries.

For typical application workloads, both UUID v4 and NanoID have extremely low collision probabilities if generated with good random sources. Still, a few guidelines help:

• Use the browser's cryptographically secure random generator where possible.
• Don't manually truncate IDs unless you've understood how that impacts collision risk.
• If an ID is security-sensitive (e.g. used as an access token), treat it with the same care as any secret.

Random IDs (UUID v4, standard NanoID) are great for uniqueness but not ideal for natural ordering:

• Database indexes on fully random IDs can become fragmented, affecting write performance.
• If you need sortable IDs, consider time-based UUID variants or storing separate created_at fields for ordering.
• For most small and medium-scale systems, the simplicity of random IDs outweighs the performance downsides.

IDs often show up in logs, URLs, and occasionally in user-visible areas. A few practical tips:

• For debugging, shorter NanoIDs can be easier to visually compare.
• Avoid exposing internal IDs directly where enumeration attacks are a concern.
• Consider redacting or hashing IDs in log files for sensitive systems.

The UUID / NanoID tool uses browser primitives to generate high-quality randomness wherever possible. At a high level:

• For UUID v4, the tool fills a 16-byte buffer with random values and sets the appropriate version/variant bits as defined by RFC 4122.
• For NanoID, the tool repeatedly samples random bytes and maps them into a URL-safe alphabet until the desired length is reached.
• All logic runs entirely in your browser — nothing is sent to Birdor's servers.

Even though IDs themselves are not secrets, they often reference sensitive resources (users, sessions, internal objects). The tool is designed with that in mind:

• ID generation is fully client-side, with no logging of generated values.
• No analytics events are attached to specific ID contents.
• You can safely generate IDs for local experiments or prototyping without tying them to any remote state.

• JSON Formatter & Viewer — useful when IDs are part of larger JSON payloads or API bodies.
• Hash Generator — helpful if you need to derive checksums or fingerprints from IDs.

In many systems, you'll use IDs together with hashing and JSON operations. Keeping these tools side-by-side can make debugging and integration work much faster.