DanfioSearch tools/

Type a tool name, a pinyin spelling or a synonym - both languages are searched.

UUID & Random String Generator

Global tools

This page makes identifiers: version 4 UUIDs (122 random bits, carrying no information at all), version 7 UUIDs (a millisecond timestamp in front, so the values sort by creation time) and plain random strings from an alphabet you choose. Everything is generated in your browser from the operating system’s own random source, so nothing is requested from a server and nothing is logged.

UUID & Random String Generator - Danfio

https://danfio.com/tools/uuid-generator/ - printed from this page

Version 4 is random and says nothing; version 7 starts with the time so the values sort; the last mode reads UUIDs you already have.

A batch of 500 is generated in a few milliseconds and is exactly what a seed file wants.

Leave it blank for "uuids.txt" - or "random-strings.txt" and "uuid-report.txt" in the other modes.

Results update as you type. Nothing leaves your device.

Random UUIDs, version 4

5 values

Every value carries 122 random bits and no information about this device, this browser or the time. It is the version to use when the identifier should say nothing at all.

Version
4
Random bits
122
Characters
36
Size
16 bytes

Your UUIDs

5ebe1d28-5832-4623-9042-89806fb4defe
3b04048e-f2b1-48f7-96b0-95aafc352bbe
59f2a5ca-ebbf-4d25-a91c-befb11a04b7c
cffc1d29-af7b-4ddb-9451-e98bcccdca81
3e7e39bb-d3ee-4139-8277-8a35b5eff0bb

One per line. Copy the lot, or download them as a .txt file - either way they were made here, in this tab.

What the numbers do not say

  • 122 bits is the whole 128 minus the six the specification spends on the version and the variant. Two values colliding is about as likely as guessing one of them: you would need roughly 2.3 x 10^18 UUIDs before a collision became as likely as not.
  • Version 4 values do not sort. In a database they land at random across the index, which is a real cost at scale - version 7 is the answer to that, and this page generates both so the difference can be seen.
  • A UUID is a good identifier and a poor secret. Treating one as unguessable is fair at 122 bits, but the values end up in database rows, request logs and analytics as a matter of course, so anything that has to stay private needs a secret with a life cycle rather than an identifier.
Generated in this browser tab from the operating system's own random source. No value was requested from a server and none was sent anywhere.

It also goes the other way. Paste UUIDs you already have — one per line, in any of the shapes they arrive in — and each one is read back for what it is: which version, which variant, and for the time-based versions the exact moment it names, plus the machine-address fingerprint that version 1 values leak.

About this uuid & random string generator

Identifiers that must never collide are what this page produces: version 4 UUIDs from 122 random bits, version 7 UUIDs with a millisecond timestamp in front so they sort by creation time, and plain random strings from an alphabet you choose. It also reads existing UUIDs back and reports version, variant and time.

The format comes from RFC 4122 and its successor RFC 9562, and the page follows both rather than inventing a shape. Randomness is drawn from the browser’s own cryptographic source, so no value is predictable from the last one. It is generated local to the tab: no server is asked for an identifier and none is logged.

A UUID is a format rather than a checksum, so the check mode reports what a value is and refuses to call it genuine. Version 1 is not offered here, because its node field once carried the machine’s MAC address. For uniqueness without coordination between machines, that refusal is the whole reliability argument.

How this uuid & random string generator works

What a UUID actually contains

A UUID is 128 bits written as 32 hexadecimal digits in the 8-4-4-4-12 shape. Six of those bits are not free: four hold the version and two hold the variant, a field that says which family of UUIDs the value belongs to. The RFC 4122 variant — the one every modern generator writes — starts with the bits `10`, which is why the first character of the fourth group is always 8, 9, a or b.

That leaves 122 random bits in a version 4 UUID, not 128. It is still an enormous number: you would have to generate roughly 2.3 × 10^18 values before a collision became as likely as not, which is the same order as guessing one specific value. The practical reason version 4 is used everywhere is not that the odds are perfect but that no coordination is needed: two machines that never speak to each other will not collide.

A UUID is a format rather than a checksum. Nothing inside the value can tell you that it was ever issued, so a mistyped digit that happens to land on another valid value reads perfectly. That is why the check mode here reports what a value is and refuses to claim that it is real.

Version 4 against version 7, and why the choice matters in a database

Version 4 is pure randomness, so consecutive values are unrelated: in a database index they land at random, splitting pages and causing writes that touch far more of the index than they need to. At small scale nobody notices; at a few hundred million rows it is the difference between an insert that appends and an insert that scatters.

RFC 9562 (2024) added version 7 for exactly this: the first 48 bits are a Unix millisecond timestamp, so values sort by creation time and inserts append to the end of an index. That costs information — everybody who holds the value knows when the row was created — and leaves 74 random bits rather than 122. Both versions are one click apart on this page so the trade can be seen rather than argued about.

Versions 1 and 6 are the older time-based pair, and they are not generated here. They end with a 48-bit node field, which older implementations filled with the real MAC address of the network card: a value that can be looked up to a manufacturer and that used to be a stable fingerprint of the machine. A web page has no business reading a MAC address, so this one does not.

Randomness, alphabets and how many bits you actually get

Everything here is drawn from `crypto.getRandomValues`, the platform’s entropy source, which is seeded by the operating system and cannot be predicted from previous output. `Math.random()` would have been shorter to write and is the wrong tool: it is a fast statistical generator whose internal state can be recovered from enough of its output, which is fine for a color and not fine for an API key.

For random strings the alphabet is the whole decision, because it sets how many bits each character is worth. Hexadecimal is four bits per character, base64url is six, letters and digits together are 5.95. Length is what buys safety, and it is cheap: 32 base64url characters is 192 bits, past the point where guessing stops being the cheapest attack. The look-alike-free alphabet trades a little strength for being readable down a phone line.

The characters are drawn without bias. The usual shortcut, taking a random byte modulo the size of the alphabet, gives the first characters a slightly higher chance whenever the alphabet does not divide 256 exactly — about 1.6% for letters and digits. Bytes that would have caused that skew are discarded instead, at the cost of a few extra bytes per string.

Worked examples

Each example below was run through the calculator on this page when the site was built, so the numbers match what you see when you enter the same inputs.

A batch of version 4 UUIDs for a seed file

What to make: UUIDs, version 4 - random, carry no information · How many: 5 values

Random UUIDs, version 4

5 values

Every value carries 122 random bits and no information about this device, this browser or the time. It is the version to use when the identifier should say nothing at all.

Version: 4 · Random bits: 122 · Characters: 36 · Size: 16 bytes

Five random UUIDs, one per line, ready to paste into a fixture or a migration. Every value carries 122 random bits and says nothing about this device.

Version 7 UUIDs, so the inserts sort

What to make: UUIDs, version 7 - start with the time, so they sort · How many: 5 values

Time-ordered UUIDs, version 7

5 values

Every value starts with the millisecond it was made, so the list is already in time order and inserts land at the end of an index instead of scattering across it. 74 bits of each value are random.

Version: 7 · Random bits: 74 · Timestamp bits: 48 · Size: 16 bytes (36 characters as text)

Each value starts with the millisecond it was made, so the list is already in time order. Values made inside the same millisecond are ordered by their random bits, which is the honest limit of the format.

Reading a list of UUIDs that already exist

What to make: Check UUIDs I already have

Checked 8 lines

7 of 8 are UUIDs

1 line is not a UUID: the report says what is wrong with each one. Versions found: version 4, version 7, version 1, version 5, the nil UUID.

Read: 8 · UUIDs: 7 · Not UUIDs: 1 · Name a moment in time: 2

Every line is reported separately: the version, the variant, and for time-based values the moment they name. A version 1 value also shows the node field it was built with, and a line that is not a UUID says why.

A 32-character token from the base64url alphabet

What to make: Random strings - an alphabet and a length · How many: 3 values · Characters per string: 32 characters · Characters to draw from: Base64url (A-Z a-z 0-9 - _), 6 bits per character

Random strings from Base64url

3 strings

32 characters each, 192 bits of randomness per string: the characters are drawn from a 64-character alphabet, which is the number that decides how hard a string is to guess.

Length: 32 characters · Alphabet: 64 characters · Bits each: 192 · Bits in the batch: 576

192 bits per string: the characters are drawn from a 64-character alphabet, so each one is worth exactly six bits. That is the shape most session tokens and API keys take.

Frequently asked questions

Is a UUID random?

It depends entirely on the version, and the version is the fourth character of the third group. Version 4 is 122 random bits. Version 7 is a millisecond timestamp followed by 74 random bits. Versions 1 and 6 are a timestamp plus a counter and a machine field, with no randomness at all. Versions 3 and 5 are hashes of a name, so they are completely predictable to anybody who knows the name. Reading a value without knowing its version is how people end up trusting an identifier that was never random in the first place.

Can two UUIDs collide?

Version 4 values collide with the odds you would expect from 122 independent bits: about one chance in 2.3 × 10^18 per pair, and by the birthday bound you would need of the order of 2^61 values before a collision became likely. That is far beyond what any single system generates, which is why nobody coordinates UUIDs: two machines that never speak will not produce the same value. The realistic failure mode is not a mathematical collision but a broken random source, which is a different problem - and the reason this page reads from the operating system rather than from `Math.random()`.

Can I use a UUID as a password reset token or an API key?

Technically 122 random bits is more than enough to be unguessable, and that is not the weak point. The problem is that UUIDs are identifiers, so they get logged: database rows, request logs, analytics, error reports and shared screenshots all carry them as a matter of course. A token that appears in a log file is a credential that has leaked. Use a random string long enough for the job (this page makes those too) with an expiry, a single use, and a server-side record, and keep it out of URLs that get logged.

Should I use version 4 or version 7 for a primary key?

If inserts have to be fast at scale, version 7: because the timestamp is the most significant part, the values sort by creation time, so new rows append to the end of the index instead of scattering across it. If the creation time of a row is something you would rather not publish, version 4. The cost of version 7 is bounded and worth stating plainly: 48 bits of every value are a clock reading, and anybody holding one can convert it back to a moment. For most tables that is not a secret; for some it is. Both options are one click apart here.

Why does this page not generate version 1 or version 6 UUIDs?

Because versions 1 and 6 end with a 48-bit node field, and the original implementations filled it with the MAC address of the network card: a value that identifies the manufacturer and, for a long time, a stable fingerprint of one machine. A browser page has no business reading a MAC address, and writing a random value into that field would produce a UUID that looks like the real thing without being it. Version 7 is the modern answer to the same problem - time-ordered without borrowing an address.

How do I make a version 5 UUID (the hash of a name)?

Take the bytes of a namespace UUID (RFC 9562 lists the standard ones for DNS, URLs, OIDs and X.500 names) followed by the bytes of the name, hash them with SHA-1, keep the first 16 bytes, then set the version nibble to 5 and the variant bits. It is not generated here because it is not random - the whole point is that `example.com` always produces the same UUID, which makes it perfect for repeatable imports and useless for anything secret. The algorithm is short enough to implement against the specification, and this page will happily read the result back and tell you it is a version 5.

Do the values generated here reach your server?

No. Everything is generated by `crypto.getRandomValues` in your own browser tab, the download is a file built locally, and there is no endpoint behind the page that could accept a value even if it wanted one. The batch of UUIDs in the static HTML was generated once, when the site was built - that is what you see before any JavaScript runs, and it is a real example rather than a placeholder. Press "Generate again" and every value on the page is made on your device.

What are the nil and max UUIDs?

RFC 9562 defines two special values: the nil UUID is all zeros and the max UUID is all ones. Neither is an identifier. They are useful in queries and in range checks - the nil value as "nothing here", the max value as the top of the range so a `between` query can be written without knowing the largest value in the table. The check mode here recognizes both and says so, because a row keyed by all zeros is usually a bug rather than a decision.

Assumptions and sources

  • Identifiers follow RFC 9562: version 4 carries 122 random bits, and version 7 puts a millisecond timestamp first so a batch sorts by time.
  • Randomness comes from your browser's cryptographic random source rather than a predictable generator, and each character is drawn without bias.
  • Values are made on your device and never uploaded; the page does not read a device fingerprint.

Last reviewed 2026-09-16. Runs locally on your device; keep backups; no financial advice applies. Read the full disclaimer.

Where a figure on this page comes from an official agency — HUD, IRS, FICO or a state body — the site keeps a dated snapshot of the source page in its sources library, and a scheduled job re-checks that snapshot, so the number can be traced back to the document it came from.

Related tools

Base64 Encoder & DecoderDeveloper ToolsEncode text to base64 or decode it back, in your browser, with the standard and URL-safe alphabets, UTF-8 handled properly, percent-encoding and data URLs too.Encode or decode Base64 →JWT Decoder & Hash GeneratorDeveloper ToolsDecode a JSON Web Token and see what every claim means, check an HS256 signature against a secret, and hash text with SHA-256, SHA-1 or MD5 in the browser.Decode a JWT →JSON Formatter & ValidatorDeveloper ToolsPaste JSON and get it formatted, minified or sorted, with the line and column when it is broken plus hints for the four mistakes everyone makes. No upload.Format and validate JSON →JSON to CSV ConverterDeveloper ToolsTurn a JSON array into a CSV table, or a CSV table into JSON, in your browser. Quotes, other delimiters, ragged rows and formulas handled. Nothing uploaded.Convert JSON to CSV →Color ConverterDeveloper ToolsConvert between hex, rgb() and hsl() in your browser: paste one color, get all three formats and an sRGB channel preview.Convert hex, rgb and hsl →Cron Expression GeneratorDeveloper ToolsTurn a cron expression into plain English and the next run times: five fields or six, Vixie or Quartz, in any time zone, with the traps named. No upload.Build a cron expression →