UUID Generator

Generate random UUID v4 identifiers instantly. Runs entirely in your browser. Nothing is sent to any server.

Options

Version

Quantity

Format

Standard (hyphens) No hyphens Uppercase Braces {}

UUIDs

What is a UUID?

A Universally Unique Identifier (UUID) is a 128-bit number used to identify information in computer systems. When generated according to standard methods, UUIDs are practically unique across space and time, without requiring a central registration authority to administer them.

Version Comparison

Version 1: Timestamp + Node

Combines a 60-bit timestamp with a node identifier. Roughly sortable by creation time. This tool fills the node segment with random bytes rather than a real MAC address, so it never leaks machine-identifying data.

Time-basedNot deterministic

Version 2: DCE Security

Defined by the old DCE (Distributed Computing Environment) spec: it overwrites part of the timestamp and the clock sequence with a local domain and a POSIX UID/GID. This tool doesn't offer it (almost no modern UUID library does) because it was only ever loosely specified, the substitution destroys most of the timestamp's precision, and it never saw real adoption outside legacy DCE/NCS systems. RFC 9562 keeps it only for historical completeness.

HistoricalNot implementedDCE Security

Version 3: Name-based (MD5)

Hashes a namespace UUID plus a name with MD5. The same namespace and name always produce the same UUID, which makes it useful for generating stable IDs from existing identifiers, but MD5 is a legacy, weak hash.

DeterministicMD5Namespace + name

Version 4: Random

Generates UUIDs entirely from random or pseudo-random numbers. It is the most common version, providing excellent distribution and minimal chance of collision. Ideal for general-purpose unique identifiers.

RandomMost common

Version 5: Name-based (SHA-1)

Same idea as v3, but hashes the namespace + name with SHA-1 instead of MD5. The recommended choice whenever you need a deterministic, name-derived UUID.

DeterministicSHA-1Namespace + name

Version 6: Reordered Timestamp

A field-compatible reordering of v1: the same 60-bit timestamp, but with the most significant bits first. That makes v6 UUIDs sort correctly as plain strings, fixing v1's main weakness for database indexes.

Time-orderedDB-friendly

Version 7: Unix Timestamp + Random

Combines a Unix millisecond timestamp with random data. Because they are time-ordered, v7 UUIDs are highly efficient for database indexing (like B-trees) compared to the completely random v4, while maintaining excellent uniqueness.

Time-orderedDB-friendlyRecommended

Version 8: Custom

RFC 9562 leaves v8 entirely vendor/application-defined: only the version and variant bits are fixed. This tool fills the free-form bits with random data as a generic example; a real system would define its own layout.

CustomVendor-specific

Examples

Generate a random (v4) UUID natively, no libraries required in most languages:

JavaScript

crypto.randomUUID()

Python

import uuid
uuid.uuid4()

Java

UUID.randomUUID()

Guid.NewGuid()

import "github.com/google/uuid"

uuid.New()

PHP

Ramsey\Uuid\Uuid::uuid4()

Ruby

require 'securerandom'
SecureRandom.uuid

Use Cases

Database primary keys

Generate IDs on any node without a central sequence or coordination. Useful for sharded databases and systems with multiple writers. Prefer v7 here: it's time-ordered, so inserts stay clustered and B-tree indexes stay efficient.

Idempotency keys

Attach a UUID to an API request so retries (from a flaky network, a timeout, a double-click) are recognized as the same operation instead of being processed twice.

Correlation & trace IDs

Tag a request with a UUID when it enters your system and pass it through every downstream service call and log line, so you can follow one request across a distributed system.

File and object naming

Name uploads, generated files, or objects in storage (S3-style buckets) with a UUID to avoid collisions between users or concurrent uploads, without needing to check what already exists.

Offline-first / client-generated IDs

Let a mobile app or offline form generate its own ID before it ever reaches a server: no round-trip needed to get a unique identifier, and no collision risk when the record eventually syncs.

Frequently Asked Questions

What is the probability of a UUID collision?

For a v4 UUID, there are 2^122 possible combinations. You would need to generate 1 billion UUIDs per second for about 85 years to reach a 50% chance of a single collision. For all practical purposes in software development, the probability is zero.

Is this tool secure?

Yes. Generation happens entirely in your local browser using the Web Crypto API's crypto.getRandomValues(). No data is sent to or stored on any server.

Which UUID version should I use?

For most general-purpose IDs, use v4 (random) or v7 (time-ordered). Pick v7 when the UUID will be a database primary key or you need rows to insert in roughly chronological order: it sorts correctly and is friendlier to B-tree indexes than v4. Use v5 when you need the same input (a namespace + name) to always produce the same UUID; avoid v3, which does the same thing with the weaker MD5 hash. v1 and v6 are timestamp-based like v7 but embed a node identifier; v6 is the sortable fix for v1's byte ordering. v8 is for custom, application-defined layouts.

Why isn't Version 2 available?

Version 2 (DCE Security) replaces part of the timestamp and clock sequence with a local domain and a POSIX UID/GID. It's shown in the comparison above for completeness, but it isn't offered by this generator: it was only ever loosely specified, the substitution destroys most of the timestamp's precision, and it never saw real adoption outside legacy DCE/NCS systems.

What's the difference between v1, v6 and v7?

All three embed a timestamp, but they order it differently. v1 puts the low bits of the timestamp first, which means v1 UUIDs don't sort correctly as plain strings. v6 is a field-compatible reordering of v1 that fixes exactly that. v7 goes further: it uses a plain Unix millisecond timestamp instead of the 1582 Gregorian epoch, which is simpler and is the version now recommended by RFC 9562 for new systems.

Are v3 and v5 UUIDs safe to use?

They're deterministic, not secret: anyone who knows the namespace and name can regenerate the exact same UUID, so don't use v3/v5 for anything that needs to stay unguessable (session tokens, password reset links). For that, use v4 or v7. Between v3 and v5 themselves, prefer v5: it uses SHA-1 instead of the weaker, deprecated MD5 that v3 relies on.

Is a GUID the same as a UUID?

Yes, for all practical purposes. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit identifier defined by the UUID standard. They're structurally identical and interchangeable in the vast majority of cases. The one historical wrinkle: some old Microsoft tooling and the COM/Windows API stored the fields in a different byte order (mixed-endian) on the wire, so double-check the byte layout if you're interoperating with very old Windows/COM code. Every UUID this tool generates follows the standard RFC 9562 (big-endian) layout used everywhere else.