Generator

UUID Generator

Generate UUIDs of every version directly in the browser. Random v4, time-based v1, sortable v6 and v7, name-based v3 and v5 from a namespace and a name, plus the special NIL and MAX values, all sit in one panel. You can generate a single value or a batch, switch to uppercase, drop the hyphens, or wrap the result in braces, and copy any line with one click. Everything is computed locally, so no identifier is ever sent to a server.

  • Every UUID version in one place: v1, v3, v4, v5, v6, v7, plus the NIL and MAX values
  • Name-based v3 and v5 from the standard DNS, URL, OID, and X.500 namespaces or a custom one
  • Batch generation with click-to-copy rows, copy all, and a plain-text download
  • Output formatting for uppercase, hyphen-free, and brace-wrapped variants
  • Generated entirely in the browser, so identifiers never leave your machine
tools/UUID Generator
UUID v4

Random, with 122 bits of randomness. The most common choice for general use.

0 results
No UUIDs yet. Adjust the options to generate.
Quick actions

Overview

Bring every UUID version into one panel so you can pick the right kind for the job, generate it in the volume you need, and format it to match your codebase, without stitching together a script or a shell command.

  1. 01

    Random versions: v4, v1, v6, v7

    Generate the versions that carry randomness or time. v4 is fully random, v1 is time-based, and v6 and v7 are better suited to time-ordered database locality.

  2. 02

    Name-based versions: v3 and v5

    Derive a stable UUID from a namespace and a name. The same namespace and name always produce the same value, which is useful for deterministic identifiers.

  3. 03

    Standard and custom namespaces

    Pick the predefined DNS, URL, OID, or X.500 namespace, or paste any valid UUID as a custom namespace for your own scheme.

  4. 04

    Single value or batch

    Generate one UUID or a list of up to a thousand at once, with quick presets for common counts when you need test data in bulk.

  5. 05

    Output formatting

    Switch to uppercase, remove the hyphens for compact storage, or wrap each value in braces to match registry-style identifiers.

  6. 06

    Copy and export

    Copy any single line with one click, copy the whole batch, or download the list as a plain-text file for scripts and test data sets.

How to use

Go from picking a version to a copy-ready list in a few steps, whether you need one identifier or a batch of test data.

  1. 01

    Choose the UUID version. Use v4 for general random IDs, or v7 when you want keys that sort by creation time.

  2. 02

    For v3 or v5, pick a namespace and type a name, or paste a custom namespace UUID of your own.

  3. 03

    For the random versions, set how many you want, or tap a count preset for a quick batch.

  4. 04

    Adjust the format if needed: uppercase, hyphen-free, or wrapped in braces.

  5. 05

    Copy a single line, copy the whole list, or download it as a text file for your scripts and tests.

Details

UUIDs show up across databases, message queues, distributed systems, and test data sets, and different situations call for different versions and formats.

  • Supports the full UUID family: v1, v3, v4, v5, v6, v7, and the NIL and MAX special values
  • Name-based v3 and v5 accept the standard DNS, URL, OID, and X.500 namespaces or any custom UUID
  • v7 produces roughly time-ordered keys that keep insert locality high in B-tree database indexes
  • v6 reorders the v1 fields so older identifiers sort before newer ones without losing the timestamp
  • Batch generation creates up to a thousand values at once for seeding databases and load tests
  • Per-line copy, copy all, and text download cover both one-off needs and bulk test data
  • Uppercase, hyphen-free, and brace-wrapped formats match different storage and platform conventions
  • Invalid custom namespaces are caught before generation, so v3 and v5 always produce a valid result
  • The time-based versions here use a random node identifier, so no real hardware address is exposed; name-based versions use standard hashing
  • All generation runs in the browser, which keeps identifiers for internal systems off any server

Use cases

Picking the right UUID version is part design decision, part convention, and the same tool needs to serve database keys, deterministic IDs, and quick test data alike.

  1. Primary keys and database rows

    Random v4 keys avoid collisions across services, while v7 keeps new rows close together in the index for faster inserts and range scans.

  2. Sortable, time-ordered identifiers

    When records should roughly follow creation order, v7 and v6 carry time information that keeps identifiers chronological enough for locality; keep a timestamp column for exact ordering.

  3. Deterministic IDs from content

    v5 turns a namespace and a stable name, such as a URL or a file path, into the same UUID every time, which is handy for idempotent imports and caching.

  4. Correlation and trace IDs

    A v4 UUID per request or message gives logs, queues, and traces a unique handle to follow a unit of work across services.

  5. Test data sets

    Batch generation seeds databases, mock APIs, and snapshot tests with realistic identifiers without writing a generator script.

  6. API resources and idempotency keys

    Clients can attach a UUID to a request so a retried call is processed once, and resources get stable public identifiers that are safe to expose.

  7. Filenames and object storage keys

    A hyphen-free UUID makes a compact, collision-resistant name for uploads, exports, and object keys that avoid clashing on shared storage.

  8. Placeholders and reset values

    The NIL UUID is a clear empty value for optional foreign keys and default columns, and MAX is useful as an upper bound in range checks.

See also

When you also need shorter random strings, numeric IDs, or prefixed keys instead of full UUIDs, the broader ID Generator covers those formats. When you want to derive or verify the hash behind a name-based UUID, the Hash Generator computes MD5, SHA-1, and SHA-256 from the same kind of input.

Best practices

A UUID is easy to generate, but choosing a version and treating it correctly is what keeps a system fast, private, and predictable.

  • Default to v4 for general identifiers, and reach for v7 when the keys should sort by creation time.
  • Prefer v7 over v4 for high-volume database primary keys, since time ordering keeps index inserts local and reduces fragmentation.
  • Use v5 rather than v3 for new name-based identifiers, because SHA-1 is preferred over MD5 in the specification.
  • Treat UUIDs as identifiers, not secrets. Do not use them as session tokens, password resets, or anything that must be unguessable.
  • Store UUIDs in a native UUID or binary column when the database supports it, rather than as a 36-character string, to save space and speed up comparisons.
  • Keep one canonical format in storage, usually lowercase with hyphens, and only apply uppercase or hyphen-free variants at the edges that require them.
  • Remember that v1 and v6 embed a timestamp and v3 and v5 are derived from their input, so none of them are random or private by nature.
  • For deterministic v3 or v5 values, document the exact namespace and name so the same identifier can be reproduced later.

Limitations

UUIDs solve identification, not security, and the guarantees differ sharply between versions, so it helps to know what they do and do not promise.

  • UUIDs are not secrets. v1 and v6 expose a timestamp, and v3 and v5 are reproducible from their input, so none of them should gate access.
  • Uniqueness is overwhelmingly likely for random and time-based versions but not mathematically guaranteed, so unique constraints still belong in the database.
  • The time-based versions here use a random node, not a real network address, so they cannot identify a physical machine.
  • Name-based v3 and v5 are deterministic, so generating many of them with the same namespace and name simply repeats one value.
  • This tool generates UUIDs and formats them. It does not parse, validate, or decode a UUID that you paste in.
  • Sortable v6 and v7 order roughly by time, but they are not a substitute for a precise timestamp column when exact ordering matters.
  • Different platforms expect different formats, so confirm whether your target wants lowercase, uppercase, hyphens, or braces before storing values.

FAQ

Common questions about generating UUIDs across versions, covering which version to pick, how name-based values work, formatting, and the limits of what a UUID guarantees.

Which UUID version should I use?

Use v4 for general random identifiers. Choose v7 when you want database keys that sort by creation time, and v5 when you need the same identifier to come from the same input every time.

What is the difference between v4 and v7?

v4 is fully random with no ordering. v7 puts a Unix timestamp in the high bits and randomness in the rest, so values sort roughly by creation time, which is better for database index locality.

How do name-based v3 and v5 work?

They hash a namespace UUID together with a name. v3 uses MD5 and v5 uses SHA-1. The same namespace and name always produce the same UUID, which makes the value deterministic.

When should I pick v3 over v5?

Prefer v5 for new work, since the specification recommends SHA-1 over MD5. Use v3 mainly to stay compatible with an existing system that already generates v3 values.

Are these UUIDs safe to use as secret tokens?

No. UUIDs are identifiers, not secrets. v1 and v6 expose a timestamp, and v3 and v5 are reproducible from their input. For tokens that must be unguessable, use a dedicated random secret instead.

Do v1 and v6 reveal my MAC address?

No. The time-based versions here use a randomly generated node identifier rather than a real hardware address, so they do not leak information about your machine.

Can two generated UUIDs ever collide?

A collision is astronomically unlikely for random and time-based versions, but it is not mathematically impossible, so keep a unique constraint in the database for critical keys.

What are the NIL and MAX UUIDs for?

NIL is all zeros and works as an explicit empty value. MAX is all ones, defined by RFC 9562, and is useful as an upper bound in comparisons and range checks.

Should I store UUIDs with or without hyphens?

Keep one canonical format, usually lowercase with hyphens, in storage. Use the hyphen-free or uppercase variants only at boundaries such as filenames or platforms that require them.

Are my generated UUIDs sent anywhere?

No. Every value is generated locally in the browser, so identifiers for internal systems and test data never leave your machine.

Related tools

A UUID is one kind of identifier among several. Pair this with a broader ID generator for shorter or custom formats, and with a hash tool when you want to inspect the digest behind a name-based UUID.