GUID / UUID Generator
Generate UUID v1, v4, and v5 identifiers, in bulk, entirely in your browser.
UUIDs are generated using crypto.randomUUID() for v4 or the uuid library for v1 and v5, entirely in your browser. No identifier is ever transmitted to a server; generation happens locally the moment you click.
GUID / UUID Generator
Generate UUIDs v1, v4, or v5 in multiple formats.
Inspect an Existing UUID
Paste any UUID to see its version and, for v1, the timestamp encoded in it. Checked locally; nothing is sent anywhere.
A GUID (Globally Unique Identifier), also called a UUID (Universally Unique Identifier), is a 128-bit value used to identify information without relying on a central authority to avoid collisions. They're commonly used as database primary keys, request IDs, and session identifiers.
v4 is randomly generated and the most common choice for general-purpose unique IDs. v1 is generated from the current timestamp and a node identifier, making it sortable by creation time but less private. v5 is deterministic: it hashes a namespace and a name (such as a URL or domain), so the same input always produces the same UUID.
Choosing a UUID Version
UUIDs (Universally Unique Identifiers) come in several versions, and picking the right one depends on what you're trying to achieve: randomness, ordering, or reproducibility.
UUID v4 is the default choice for most applications. Every id is generated from 122 bits of randomness, so two v4 UUIDs colliding is astronomically unlikely even across billions of records. Use it for primary keys, session tokens, and correlation IDs where you have no reason to encode extra meaning into the identifier.
UUID v1 embeds the current timestamp and a node identifier (traditionally a MAC address) directly in the id. That makes v1 UUIDs sortable by creation time, which is useful for time-series data or logs, but it also leaks information about when and where the id was generated. Avoid v1 if the identifier will be exposed publicly and anonymity matters.
UUID v5is deterministic rather than random: it's a SHA-1 hash of a namespace UUID and a name string. Feeding it the same namespace and name always produces the same output. This makes v5 useful for generating stable, collision-resistant ids from existing data, for example deriving a consistent identifier for a URL or email address without needing a lookup table.
A common mistake is treating “UUID” and “GUID” as though they imply a fixed version, but they don't. Both terms just mean a 128-bit identifier formatted as8-4-4-4-12 hexadecimal groups; the version is encoded in specific bits of the identifier itself. If you inspect the third group, the leading character tells you the version: a v4 UUID always starts that group with a 4, and a v1 UUID encodes a timestamp there instead. This is worth knowing when debugging a system that mixes identifier sources, since a “UUID that looks wrong” is sometimes just a different version than the one your code expects.
Bulk generation is also worth a note on its own. Generating a hundred v4 UUIDs at once doesn't increase collision risk in any meaningful way: each one draws independently from the same 122 bits of randomness, so the probability of any two matching stays astronomically small regardless of batch size. That makes bulk generation safe for seeding test fixtures, pre-allocating ids for a batch import, or generating placeholder keys before a database write actually happens.
Common Use Cases
Database primary keys
v4 UUIDs are a common choice for primary keys in systems where rows get created by multiple services or clients at once, since no central counter is needed to avoid collisions the way an auto-incrementing integer requires.
Request and correlation IDs
Tagging an incoming API request with a fresh v4 UUID and threading it through logs and downstream calls makes it possible to trace a single request across services after the fact, without any coordination between them.
Idempotency keys
Payment and write APIs often ask clients to attach a unique key so a retried request doesn't get processed twice. A v4 UUID generated once per logical operation, and reused on retry, is a standard way to satisfy that.
Deduplicating imported records
When importing data from an external source (a URL, an email address, a file path) v5 lets you derive the same id every time you see the same input, so re-running an import doesn't create duplicates, with no lookup table required.
Frequently Asked Questions
What is the difference between UUID v1, v4, and v5?
v4 is randomly generated and suitable for most use cases. v1 is timestamp-based and encodes the generation time and MAC address, so avoid it if anonymity matters. v5 is deterministic: given the same namespace and name, it always produces the same UUID, making it useful for deriving stable IDs from known inputs like URLs.
Are the GUIDs generated here truly random?
Yes. v4 UUIDs are generated using crypto.randomUUID(), which draws from the operating system's cryptographically secure random number generator. They are not predictable.
Can I use these GUIDs in a production database?
Yes. UUID v4 identifiers are safe for use as primary keys, partition keys, or correlation IDs. Collision probability is negligible for any realistic volume.
What does "compact" format mean?
The compact format removes the four hyphens from the standard 8-4-4-4-12 representation, giving a 32-character hexadecimal string. Both formats represent the same identifier.
Further Reading
What Is a UUID?
What a UUID is, why it exists, and how versions 1, 4, and 5 differ.
UUID vs Auto-Increment ID: Which Should Your Database Use?
When a UUID primary key is worth the tradeoffs over a simple auto-increment integer, and when the integer is still the better choice.
How to Generate a UUID in JavaScript, Python, and Go
A quick reference for generating a version 4 UUID in JavaScript, Python, and Go, using each language's built-in tools, no third-party dependency required.