Online UUID Generator Tool

1. 1

   Choose the UUID version

   Version 4 is random and the safe default. Version 7 is time-ordered and the better choice for a database key. Versions 3 and 5 turn a name into an identifier that never changes. Versions 1 and 6 embed a timestamp, and Nil and Max are the two fixed special values.

2. 2

   Set how many you need

   Type a number or use a preset. One hundred per click is free; larger batches, up to a million at a time, are the Pro axis. For versions 3 and 5 the count comes from the list of names you paste instead.

3. 3

   Choose how they should look

   Switch between lowercase and uppercase, turn the hyphens off for a compact form, wrap the values in braces or the urn:uuid: prefix, and add a prefix or suffix if you are pasting straight into code.

4. 4

   Generate

   Press the generate button. Every value is produced on your device from its cryptographic random source, with nothing sent to a server.

5. 5

   Copy or export

   Copy one value with the button beside it, copy the whole batch at once, or download the list as plain text, JSON, CSV or Base64.

6. 6

   Check identifiers you already have

   Switch to Check mode and paste a list, or drop a text, CSV, JSON or log file in. Each value is reported with its version, variant, embedded creation time and node, and duplicates are counted.

RFC 9562 replaced RFC 4122 in May 2024 and added three new versions and two special values. This page generates every one that a browser can honestly produce. Each entry below says what the value contains and the one situation it is the right answer to.

• Version 4 — random — 122 bits of randomness and nothing else. Unpredictable, carries no information about when or where it was made, and the right default whenever you have no specific requirement beyond uniqueness.
• Version 7 — time-ordered — A 48-bit millisecond timestamp followed by randomness. Sorts by creation time as a plain string, which is what makes it the modern recommendation for database primary keys. New in RFC 9562.
• Version 1 — time-based — A 60-bit timestamp counted in 100-nanosecond intervals since 1582, plus a clock sequence and a node. Widely supported and widely deployed, but its field order means the strings do not sort by time.
• Version 6 — time-based, reordered — The same three fields as version 1, stored most-significant first so that the strings do sort. Intended as the drop-in replacement for version 1 in systems that cannot move to version 7.
• Version 3 — namespace with MD5 — A hash of a namespace and a name. Deterministic: the same inputs always give the same identifier. Kept for compatibility with systems that already use it.
• Version 5 — namespace with SHA-1 — The same idea as version 3 with a different hash, and the one to choose for new deterministic identifiers.
• Nil — Thirty-two zeros. A defined special value, not a version, and conventionally means the absence of an identifier.
• Max — Thirty-two f characters. The other defined special value, and the largest a UUID can be — useful as the upper bound of a range.

Version 2 is defined but not generated here, and that is deliberate rather than an oversight. It reserves the low 32 bits of the timestamp for a POSIX user or group id, which a web page cannot know, so every online version 2 generator produces something that is structurally correct and semantically meaningless. Version 8 is reserved for experimental and vendor-specific layouts and has no fixed meaning to generate against.

This is the decision people actually arrive with, and it has a clear answer that has changed in the last two years.

• Use version 7 — for any new primary key. Its values increase over time, so each insert lands at the end of the index rather than at a random point in the middle.
• The problem with version 4 keys — is not uniqueness, it is write locality. Random keys scatter inserts across the whole B-tree, so the pages being written are spread through the index and the ones you need are less likely to be in memory. On a large, busy table this shows up as slower inserts and a larger index.
• Do not use version 1 for this — even though it is time-based. Its low-order timestamp field comes first, so the strings do not sort in creation order and it behaves like a random key as far as the index is concerned.
• Store them compactly if you can — A UUID is 16 bytes; written as a hyphenated string it is 36. Databases that offer a native UUID or binary(16) column will use a quarter of the space of a char(36) and compare faster.
• Be consistent about case and hyphens — Two services storing the same identifier in different forms will not match on a string comparison. Pick one representation at the boundary and normalise on the way in.

Every setting on this page is free, and only the batch size has a plan boundary. The controls split into two groups that behave differently: changing a generation setting produces new identifiers, while changing a formatting setting only changes how the ones already on screen are written.

Version

Chooses which kind of identifier is produced. This is a generation setting, so switching it replaces the values on screen rather than reformatting them. The hint under the picker changes with your choice and says in one line what that version is for.

How many

Type a number or press a preset. The box will not accept a value above your plan's limit, so it can never ask for a batch the tool then refuses — a control that offers an impossible value is worse than one that does not offer it at all. For versions 3 and 5 this box is replaced by the list of names, because there the count is however many names you supply.

Case, hyphens, braces and URN

Purely presentational, and applied without regenerating anything. Compact form removes the four hyphens and is what many databases store internally. Braces are how SQL Server and older Windows APIs write a GUID. The urn:uuid: prefix is the form RFC 9562 defines for use as a URI. All four can be combined.

Prefix and suffix

Wraps every line in text of your own, which is the difference between a list you copy and a list you paste. Setting the prefix to INSERT INTO users (id) VALUES (' and the suffix to '); turns a batch into runnable SQL. The affixes are included in every export format, and CSV quotes them correctly if they contain a comma.

Export format

Plain text is one value per line. Comma separated fits an IN clause. JSON is a ready-made array. CSV carries a header row and, where the version has one, a name or creation-time column beside each value. Base64 encodes the whole list, for the places that want an opaque blob.

Switch to Check mode and paste anything — a column from a database export, a log file, a JSON body, a single value from a bug report. Every UUID-shaped token is found and reported, in any mixture of formats and cases, and a file can be dropped in instead.

• Version and variant — Both, and they are not the same question. The variant decides whether the version digit means anything at all.
• Creation time — For versions 1, 6 and 7 the embedded timestamp is decoded into a readable date. This is often the fastest way to answer when a record was created if nobody stored a created_at.
• Clock sequence and node — For versions 1 and 6, along with whether the node is a random value or a real network address — the multicast bit tells you which, and a value with a real address was made by something with access to a network card.
• Format — Hyphenated, compact, braced or urn:uuid: prefixed, reported per value, so a list that mixes representations is easy to spot.
• Duplicates — Counted across the whole list. This is the one statistic worth having on a pasted list and the one that is meaningless on freshly generated output.

Why some values are non-standard rather than invalid

The first digit of the fourth group carries the variant bits. Only the pattern 10xx marks an RFC 9562 identifier; 110x is a Microsoft COM GUID, 0xxx is a legacy NCS value, and 111x is reserved. If the variant is not the RFC one, the version digit is ordinary data and reporting it as a version invents information that is not there. A value such as 00000000-0000-9000-0000-000000000000 is thirty-two valid hex digits and has no version at all — checkers that report it as version 9 are reading a digit and calling it a fact.

These two are the odd ones out: they are not random, and they are not about time. They turn a namespace and a name into an identifier by hashing them, and the same pair always produces the same result.

• Pick a namespace — RFC 9562 defines four by name — DNS for host names, URL for addresses, OID for object identifiers and X500 for directory names. Any UUID can be used as a namespace, so a project can define its own and get a private identifier space.
• Paste the names — One per line. Each produces one identifier, and the count comes from the list rather than from the batch box.
• Reproducibility is the point — Re-running the same list next year on a different machine gives the same identifiers, which is what makes these usable for reconciling records across systems that do not share a database.
• Not a security function — MD5 and SHA-1 are both broken as cryptographic hashes. RFC 9562 keeps them here because the output is an identifier rather than an authenticator, and says so itself. Never treat a version 3 or 5 value as unguessable.

The number is large enough that intuition is not much help, so here it is concretely.

• A UUID is 128 bits. Version 4 fixes six of them for the version and variant, leaving 122 bits of randomness — about 5.3 undecillion possible values.
• To reach a one-in-a-billion chance of a single collision you would need roughly 100 billion identifiers. At a million a second that is about three years of continuous generation.
• The realistic failure is never the mathematics — it is a weak random source. This page uses the browser's cryptographic generator, which is the same source used for session keys, and never a plain pseudo-random function.
• Version 7 sacrifices some randomness for ordering: 74 random bits per value rather than 122. Still far beyond any practical collision risk, and the trade is the entire point of the version.
• Versions 3 and 5 are deterministic, so identical inputs are meant to collide. That is the feature, not a fault.

Most of the trouble people have with UUIDs comes from expecting one of these four things to be true.

• Not a secret — Identifiers end up in URLs, logs, error reports and analytics. Versions 1, 6 and 7 additionally state when they were made. Authorise every request; never let possession of an id be the check.
• Not sortable, unless you chose a version that is — Versions 4, 3 and 5 have no order at all, and version 1 only appears to have one. If you need creation order from the key itself, that means version 7 or version 6.
• Not free of cost as a key — Sixteen bytes against four for an integer, and thirty-six if stored as a string. On a table with several indexes that difference is real, and it is the reason to store them in a native or binary column.
• Not a replacement for a natural key — A UUID says two records are different. It never says two records are the same thing, which is what a real business key does.

The batch size is the only setting on this page with a plan attached. Every version, every formatting option and every export format works the same on both plans.

What Free includes

All eight kinds of identifier, all formatting, all five export formats, the full checker with CSV report, and a hundred identifiers per click. That is enough for seed data, a test fixture, a handful of keys, or looking up what is inside an id somebody sent you.

What Pro adds

Larger batches — a thousand, ten thousand, a hundred thousand, or a million at a time — and up to twenty-five list files at once on the checking side. A million identifiers is where the browser rather than the plan becomes the limit, and past that point you are warned rather than refused.

Measured in Chromium on a desktop machine: a hundred thousand version 4 identifiers are produced in about 20 milliseconds, a hundred thousand pasted values are decoded in under a tenth of a second, and exporting a hundred thousand as CSV takes about 4 milliseconds. Only the first two hundred values are drawn on screen, which is why a batch of a million still appears instantly.

An identifier generator that calls a server has to be trusted twice: once that it produces good values, and once that it does not keep them. This one removes the second question by never sending anything.

• Nothing is uploaded — Not the identifiers, not the names you paste for versions 3 and 5, not the list you drop in to check. Open your browser's network panel while you use the page and there is nothing to see.
• It works offline — Once the page has loaded, generation and checking keep working with no connection at all — useful on a locked-down network or a plane.
• The random source is the browser's own — The same cryptographic generator the browser uses for its own keys, drawn in blocks and then formatted, which is what makes a large batch fast without weakening it.

Version 2 and version 8 are not generated, for the reasons given above. Versions 3 and 5 depend on MD5 and SHA-1, which are cryptographically broken and used here only for their determinism. The checker reads any 32 hexadecimal digits in any common wrapper, but it cannot tell you whether an identifier is one your system actually issued — only what it contains. Everything on this page works in current versions of Chrome, Edge, Firefox and Safari, on desktop and mobile.

• Hash Generator
• Base64 Encoder/Decoder
• URL Encoder/Decoder
• QR Code Generator
• Barcode Generator
• JSON Formatter
• Color Converter
• Color Palette Generator
• Time and Date Converter
• JSON Validator
• CSV to JSON
• Remove Duplicate Rows
• Text Deduplicator
• Text Splitter
• Text Sorter
• Case Converter
• All converters