Zellio.io

UUID & Token Generator

Generate RFC-4122 v4 UUIDs and secure random tokens in bulk.

Runs locallyWorks offlineShare link carries settings, never your data
Send output toQR Code GeneratorPassword GeneratorFocus TimerBuild a workflow from thisOutput stays on this page until you send it.

Frequently asked questions

What is a v4 UUID?

A version-4 UUID is a 128-bit identifier whose bits are mostly random, giving an astronomically low chance of two ever colliding — perfect for unique keys and tokens. Unlike sequential IDs (1, 2, 3...) which leak information about your database size, UUIDs are random and reveal nothing about the system's state or data. The probability of a collision is so low (roughly one in 5 billion UUIDs) that it's safely ignored for most applications. v4 UUIDs generated from a good random source are ideal for database primary keys in distributed systems, API request identifiers, and any scenario requiring unique values without coordination between systems.

Are the UUIDs cryptographically secure?

Yes. They use your browser's secure random source, so they are unpredictable and safe for identifiers and tokens. The browser's crypto.getRandomValues() API provides cryptographically strong randomness suitable for security-sensitive applications, not just casual shuffling. This means generated UUIDs have no predictable pattern and cannot be guessed or brute-forced, making them safe for session tokens, API keys, and security tokens. The randomness is suitable for cryptographic purposes in most applications, though high-security systems should still validate tokens on the server side rather than trusting a client-generated identifier alone.

Can I generate many at once?

Yes — generate them in bulk and copy the whole batch for seeding databases or test fixtures. You can generate anywhere from 10 to 1,000 UUIDs at a time and copy them all in one click, formatted as a JSON array, newline-delimited list, or comma-separated values depending on your needs. This bulk generation is handy for populating test databases, creating API test data, or generating a batch of unique identifiers for a new feature launch. You can regenerate the batch as many times as you like to get a fresh set of UUIDs without manually creating each one.

Pro tips

  • Use v4 for anything user-facing or security-adjacent, where a sequential id would leak volume or ordering.
  • Prefer a time-ordered identifier for database primary keys on large tables; random keys fragment the index as it grows.
  • Never use a UUID as a security token unless it came from a cryptographic generator — a seeded pseudo-random one is guessable.
  • Generate in bulk when seeding fixtures so the same set can be pasted into two systems and still joined afterwards.
  • Store UUIDs in a native UUID column where your database offers one; keeping them as text costs roughly twice the space and slows comparisons.

About UUID & Token Generator

Produces a single value or a whole batch, drawn from your browser's cryptographic generator rather than a seeded pseudo-random one. The distinction matters as soon as the value becomes a database key or a session token.

Generate RFC-4122 version-4 UUIDs and secure random tokens one at a time or in bulk. UUIDs are 128-bit identifiers with such a vast range that collisions are practically impossible, making them ideal for database keys, request IDs and idempotency keys.

Copy a single identifier or generate hundreds at once. Version 4 is random rather than sequential, which is what makes it safe to expose in a URL but slower as a database primary key than a monotonic id.

Version 4 UUIDs draw 122 random bits, which puts collisions beyond practical concern — you would need to generate billions per second for decades before the probability became worth modelling. The real trade-off is not uniqueness but ordering. Random keys scatter inserts across a B-tree index, fragmenting it and destroying the locality that makes recent rows fast to read, which is why large tables keyed on v4 degrade in a way sequential ids do not.

Version 7 exists precisely for that, placing a timestamp in the high bits so new rows sort together and land near each other in the index while keeping random bits for uniqueness. It has become the sensible default for database primary keys, with v4 remaining right for tokens and identifiers where ordering would leak information. Version 1 is worth avoiding in anything new: it embeds the generating machine's MAC address, which is information disclosure for no benefit now that v7 is available.

Common use cases

  • Creating primary keys for records that must be unique across several databases or services.
  • Generating idempotency keys so a retried API request is not processed twice.
  • Producing correlation or request IDs for tracing a call through a distributed system.
  • Creating unguessable identifiers for a resource exposed in a URL.
  • Seeding test fixtures with stable identifiers that can be referenced across systems.
How it comparesEvery language has a UUID function, and reaching for a terminal or a REPL is slower than a browser tab already open. The bulk mode is the part worth the visit — generating a hundred at once for fixtures is awkward in most REPLs and trivial here.