UUID Generator
Generate UUID v4, v5, v7, or NanoID identifiers in bulk
Fully random 122-bit identifier — the classic default, no ordering.
About this tool
The ToolNinja UUID Generator generates UUID v4, UUID v5, UUID v7, and NanoID identifiers instantly — individually or in bulk up to 100 at a time. UUID v4 is fully random and the classic default. UUID v7 encodes a millisecond timestamp in its first 48 bits, making generated IDs sort chronologically — this has become the default recommendation for new database primary keys in 2026 because it avoids the random-insert performance penalty v4 causes on B-tree indexes. UUID v5 is deterministic — the same namespace and name always produce the exact same UUID, via SHA-1(namespace + name), making it useful for idempotency keys and stable test fixtures where you need reproducibility rather than randomness. NanoID produces a much shorter, URL-safe random string — the better choice for public-facing identifiers like share links and invite codes, where a 36-character UUID is overkill. Generate a single ID for quick use, or bulk generate up to 100 for seeding test databases or fixture data. 100% browser-based using the Web Crypto API for true cryptographic randomness. No login, no server calls required.
When to use it
- →Primary keys for database records in distributed or multi-writer systems
- →Correlation IDs for tracing requests across microservices and logs
- →File names for user-uploaded assets to prevent naming collisions
- →Idempotency keys for payment APIs and write-once operations
- →Short, URL-safe public identifiers (share links, invite codes) using NanoID mode
- →Time-sortable primary keys using UUID v7 mode, without the database index fragmentation v4 causes
Tips
- ◆The format is 8-4-4-4-12 hex digits: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The 4 indicates version 4, and the y is one of 8, 9, a, or b.
- ◆For database primary keys, UUIDs have higher storage overhead than auto-increment integers but work safely in distributed systems without a central coordinator.
- ◆For a new project in 2026 with no legacy v4 data to stay consistent with, default to UUID v7 for primary keys and NanoID for anything user-facing.
- ◆UUID v5 always produces one ID per namespace+name — generating '100' of them would just repeat the same value, so the tool intentionally limits v5 to a single result per click.
Frequently asked questions
Can two generated UUIDs ever be the same?
Theoretically yes, but practically no. The probability of a collision between two random v4 UUIDs is 1 in 2^122 (about 5x10^36). To have a 50% chance of a collision, you'd need to generate 2.7x10^18 UUIDs — far beyond any realistic system.
What's the difference between UUID v1, v4, v5, and v7?
V1 is time-based and includes the machine's MAC address — deterministic but leaks information. V4 is fully random — historically the most widely used version. V5 is deterministic from a namespace + name (SHA-1-based) — same input always gives the same UUID, useful for idempotency keys. V7 encodes a millisecond timestamp in the first 48 bits, so generated IDs sort chronologically, which avoids the random-insert performance penalty v4 causes on database indexes — it's now the recommended default for new database primary keys.
What is UUID v5 actually useful for, if it's not random?
Anywhere you need the same logical input to always produce the same ID — deduplicating records imported from an external system by hashing a stable field (like an email or external ID) into a namespace UUID, generating a stable test fixture ID that doesn't change between test runs, or building an idempotency key from a request's own content so retrying the same request never creates a duplicate.
When should I use NanoID instead of a UUID?
NanoID is a better fit for identifiers users actually see or type — share links, invite codes, short URLs — where a 36-character UUID is unnecessarily long. It's not time-ordered, so don't use it as a high-write table's primary key unless you also keep a separate created_at column for ordering.
Should I use UUID or auto-increment integers for database IDs?
Auto-increment integers are simpler and more storage-efficient. UUIDs are better when you need IDs generated client-side before writing to the database, when merging records from multiple sources, or when you don't want sequential IDs that expose record counts. If you do use UUIDs for a primary key, prefer v7 over v4 for better index locality.
Is GUID the same as UUID?
Yes. GUID (Globally Unique Identifier) is Microsoft's term for the same concept. A GUID and a UUID v4 are interchangeable in most contexts, though GUIDs are sometimes written without hyphens and may use uppercase hex digits.