GUID and UUID generator

UUID v4 is the general-purpose random choice. After the required version and variant bits are set, 122 bits remain random. It is a good default for independent clients, test data, public resource identifiers and systems that do not need the identifier itself to reveal a time.

UUID v7 puts a Unix millisecond timestamp in the most significant 48 bits, then uses random bits for the remaining variable space in this implementation. That makes values from different milliseconds sort broadly by creation time when clocks move forward, which can help log review and some index patterns.

Version 7 is not a promise of strict generation order. This generator does not add a monotonic counter or sub-millisecond sequence. Values created in the same millisecond contain random trailing bits, and a device clock that moves backward can disrupt the visible ordering.

The familiar hyphenated form is a text presentation of 16 bytes. The five groups have 8, 4, 4, 4 and 12 hexadecimal digits, but the groups are not separate random strings. The version nibble appears at the start of the third group, and the RFC variant appears in the first hex digit of the fourth group.

The fixed public v4 example 550e8400-e29b-41d4-a716-446655440000 has 4 in the version position and a in the RFC variant position. The variant digit can be 8, 9, a or b for the RFC variant because the leading bits are 10. These positions explain how inspection recognizes fields; they do not reveal whether the other bits were generated randomly. A hand-written value can imitate the same pattern.

The inspector also recognizes nil and max values as special sentinels. Nil is all zero bits; max is all one bits. They can be structurally meaningful in a protocol, but they are not random generated identifiers and should not be mistaken for ordinary unique values.

For UUID v7, ClockTools takes one device-clock millisecond timestamp for the batch and writes it into the first six bytes of each value. Each value still receives fresh random bytes before the version and variant bits are fixed. If the clock value cannot fit in the 48-bit v7 timestamp field, generation fails instead of wrapping.

The unique count is local to the current generated batch. The generator uses a Set and bounded retries so duplicate random outputs inside the requested batch are not returned. It does not consult a global registry, a database, another tab or values produced yesterday.

Probability is still not the same as a business rule. If duplicate keys would be consequential, enforce uniqueness where the identifiers are stored and handle conflict errors there. Generation cannot know the state of your application. A failed new generation clears the previous batch rather than leaving an old result looking like a successful new request, so copy needed fixtures before experimenting with the next batch.

Text format is useful when the receiver expects a printed UUID. Lowercase is the canonical browser output used by the generator, uppercase is for systems with that convention, braces and quotes are wrappers, no hyphens is the 32-hex compact form, and URN adds the urn:uuid: prefix.

Encoding is a different layer. Plain text preserves the selected text format. URL encoded output percent-encodes that text. Base64 and Base64 URL ignore the text-format wrapper and encode the 16 raw bytes in network order; the format selector is disabled for those encodings because braces or uppercase letters are not part of the byte value.

Layout decides how several values are arranged. One per line is easiest to scan. CSV creates one row of comma-separated fields. JSON array is useful for fixtures and code. SQL values creates quoted values separated by commas; it is a values list, not a complete SQL statement.

For the fixed UUID 550e8400-e29b-41d4-a716-446655440000, the byte encodings are VQ6EAOKbQdSnFkRmVUQAAA== in Base64 and VQ6EAOKbQdSnFkRmVUQAAA in Base64 URL. The ordinary text has 36 characters, compact hex has 32, padded Base64 has 24, and this unpadded Base64 URL form has 22. They represent the same 16 bytes. Encoding the 36 printed ASCII characters instead would encode a different input and would not give those byte results.

RFC 4648 describes the Base64 and URL-safe alphabets. The URL-safe form replaces the plus and slash characters used by ordinary Base64 and, in this tool, omits trailing padding. Case still matters in either Base64 alphabet; do not lowercase a Base64 value as if it were hexadecimal UUID text. URL encoded is a third choice: braces become %7B and %7D, while canonical UUID letters, digits and hyphens need no percent substitution.

Byte order is part of an interchange contract. This page encodes bytes in the same network order as the canonical hexadecimal text. Microsoft's Guid.ToByteArray documentation shows that its parameterless byte output reverses the first three field groups relative to text. If the receiver uses that representation, compare documented byte order explicitly; agreeing that both fields contain a GUID does not establish that their Base64 strings will match.

Quoting is also layered. Quoted text format adds quote characters to each value; a JSON layout then escapes those characters inside its string, and CSV escapes them inside a field. Extra escaped quotes can therefore be correct serialization but still be wrong for a receiver that wanted a bare UUID. Lowercase plus Plain text is a straightforward starting point for JSON and CSV imports. SQL values uses single-quoted strings; supply the surrounding query structure separately and prefer parameterized application queries rather than pasting generated strings into a live query.

A valid structure means the text fits a supported UUID shape and its version and variant fields can be read. It does not prove the identifier was generated by ClockTools, by Web Crypto, by a particular service or at the decoded v7 time.

For UUID v7, the timestamp is useful evidence only inside a larger investigation. It may reflect the device clock used by a generator, a deliberately altered timestamp or a copied test value. Treat it as a sorting clue, then compare server logs, database timestamps and trusted audit records.

The inspector accepts compact hex or hyphenated text, and it can remove common wrappers such as braces, parentheses, quotes or a urn:uuid: prefix before checking. It does not decode Base64, Base64 URL or URL-encoded input for validation; decode those representations in the receiving system before structural inspection.

Inspection accepts one identifier at a time, not an exported CSV row or JSON array. Use generated value pastes the first original UUID from the current batch, not its encoded display, so you can inspect a batch even while Base64 is selected. The inspector recognizes supported RFC versions 1 through 8, but generation offers only v4 and v7. An unsupported-variant warning can still display a normalized shape; it is not a successful RFC validation or permission to rewrite the source protocol's fields.

A quantity error means the count is not a whole number from 1 through 1,000. The tool does not round, clamp or silently reduce the request. A random-source error means Web Crypto did not provide usable random bytes, so no identifiers were generated.

An encoding error can occur when a browser lacks the API needed for the chosen output encoding. Switch to Plain text to recover the underlying batch or try another browser. A generation failure is different: it discards the batch rather than retaining partial values. Clipboard, share and download failures do not regenerate identifiers. When export access fails, select the visible output manually if it is available; check downloads before assuming a started file was saved.

Do not paste production secrets into a UUID report. A UUID can be public, private or security-sensitive depending on how your system uses it, but the shape alone does not make it a password. For bearer tokens, password resets or API credentials, use a purpose-built secret generator and lifecycle controls.