# UUID Generator & Inspector

> Generate v4 or time-ordered v7 UUIDs, or decode any UUID’s version, variant and timestamp.

Category: Inspect & Identify · Page: https://util.caruana.me/tools/uuid/

## API, MCP and A2A

### Generate UUIDs (`uuid_generate`)

`GET|POST https://util.caruana.me/api/uuid/generate` · MCP tool `uuid_generate` · A2A skill `uuid_generate` · [reference](https://util.caruana.me/reference/uuid_generate/)

Generates RFC 9562 UUIDs. Version 4: 122 random bits from `crypto.randomUUID()`. Version 7: a 48-bit Unix millisecond timestamp, then a 42-bit counter (randomly seeded each millisecond, incremented within it) and 32 fresh random bits, so every batch is strictly increasing in both byte and string order. UUIDs are identifiers, not secrets: do not use them as passwords, API keys, session tokens or capability URLs, even though v4 uses a CSPRNG.

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `version` | 4 \| 7 | no | `4` (random) or `7` (time-ordered; sorts by creation time, good for database keys). |
| `count` | integer (1–1000) | no | How many UUIDs to return, 1 to 1000. |
| `format` | canonical \| uppercase \| no-hyphens \| braces \| urn | no | `canonical` (lowercase 8-4-4-4-12), `uppercase`, `no-hyphens` (32 hex), `braces` ({…}), or `urn` (urn:uuid:…). |

Privacy: The server receives only the options (version, count, format), generates the UUIDs in memory with the Web Crypto CSPRNG, and returns them. Your input is not stored or logged; only the per-call metadata row (operation, time, status, sizes) is recorded. UUIDs are identifiers, not secrets: never use one as a password, token or key.

### Inspect a UUID (`uuid_inspect`)

`GET|POST https://util.caruana.me/api/uuid/inspect` · MCP tool `uuid_inspect` · A2A skill `uuid_inspect` · [reference](https://util.caruana.me/reference/uuid_inspect/)

Parses a UUID written as 8-4-4-4-12 hex, 32 hex digits, `{…}` or `urn:uuid:…` (any case) and reports its RFC 9562 variant and version, whether it is the Nil or Max UUID, and the fields its version defines: the timestamp of v1, v6 and v7 as ISO 8601 (v1/v6 to 100 ns), and the clock sequence and node of v1 and v6. It also returns the UUID in every common format.

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `input` | string (≤ 64 chars) | yes | One UUID in any accepted form, e.g. `017f22e2-79b0-7cc3-98c4-dc0c0c07398f`. |

Privacy: The server receives the UUID, decodes its fields in memory, and returns them. Your input is not stored or logged; only the per-call metadata row (operation, time, status, sizes) is recorded. Note that a v1 UUID may embed the MAC address of the machine that generated it.


## User guide

The tool sits in a window that works like a desktop app: menus on the top row and the **full-screen** icon at its right (**Esc** leaves full screen). The set-up options described below are in **Settings → Options…**, an overlay, and the **Settings** menu also lists the common choices directly. To keep the options in view instead, choose **View → Inline config**; the page remembers that choice. **Help → Keyboard shortcuts…** lists the keys.

**Generating.**

1. Choose **v4** (random) or **v7** (time-ordered), how many (1–1000), and a format.
2. Press **Generate**, then **Copy**. Changing any option generates a fresh set.

Which version should you use?

- **v4** has no structure at all: use it when you need an opaque identifier.
- **v7** starts with the creation time in milliseconds, so new IDs sort after old ones. Database indexes stay compact, and you can sort by ID instead of by a timestamp column. Anyone can read the creation time from a v7 UUID.

> **UUIDs are identifiers, not secrets.** v4 UUIDs come from a cryptographically secure generator, but they are not designed or reviewed as secrets. They are logged, put in URLs, and shown in UIs as a matter of course, and a v7 UUID is partly predictable. Never use a UUID as a password, API key, session token, password-reset token or unguessable "secret link". Use a dedicated random token of at least 128 bits for those.

**Inspecting.** Paste any UUID to see:

- its **version** and **variant**;
- whether it is the **Nil** or **Max** UUID;
- the **timestamp** of v1, v6 and v7;
- the **clock sequence** and **node** of v1 and v6;
- the same UUID in every format.

## Specification

**Standard.** RFC 9562 (May 2024), which obsoletes RFC 4122.

**Accepted input formats** (case-insensitive, surrounding whitespace ignored):

| Format       | Example                                         |
| ------------ | ----------------------------------------------- |
| `canonical`  | `017f22e2-79b0-7cc3-98c4-dc0c0c07398f`          |
| `uppercase`  | `017F22E2-79B0-7CC3-98C4-DC0C0C07398F`          |
| `no-hyphens` | `017f22e279b07cc398c4dc0c0c07398f`              |
| `braces`     | `{017f22e2-79b0-7cc3-98c4-dc0c0c07398f}`        |
| `urn`        | `urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f` |

Any other shape is rejected with the reason: the first non-hex character and its position, the number of hex digits found, or misplaced hyphens. Output always includes the canonical form, which is lowercase (RFC 9562 §4).

**Variant** (the top bits of octet 8, RFC 9562 §4.1):

| Bits  | Variant                                      |
| ----- | -------------------------------------------- |
| `0`   | NCS (reserved, backward compatibility)       |
| `10`  | RFC 9562                                     |
| `110` | Microsoft (reserved, backward compatibility) |
| `111` | Reserved (future)                            |

The **version** (top 4 bits of octet 6) is reported only for the RFC 9562 variant. The Nil UUID (all zeros, §5.9) and the Max UUID (all ones, §5.10) are identified as such and have no version.

**Fields decoded per version.**

| Version | Decoded                                                                                                                           |
| ------- | --------------------------------------------------------------------------------------------------------------------------------- |
| 1       | 60-bit timestamp `time_high‖time_mid‖time_low` in 100 ns intervals since 1582-10-15T00:00:00Z; 14-bit clock sequence; 48-bit node |
| 6       | Same fields, stored most-significant first (`time_high‖time_mid‖time_low`)                                                        |
| 7       | 48-bit Unix timestamp in milliseconds                                                                                             |
| 2       | Named only (DCE Security; its layout is not specified by RFC 9562)                                                                |
| 3, 5    | Named; the MD5 or SHA-1 name hash cannot be reversed                                                                              |
| 4, 8    | Named; random or vendor-defined bits                                                                                              |

**Timestamps.**

- **Units:** v1 and v6 timestamps are converted with the Gregorian-to-Unix offset 122,192,928,000,000,000 × 100 ns.
- **`isoExact`** has 7 fractional digits, which is exact to 100 ns.
- **`iso` and `unixMs`** are floored to the millisecond.
- **Node:** for v1/v6, `nodeIsRandom` is true when the multicast bit of the node is set (§6.10). Otherwise the node may be the generating machine's MAC address.

**Test vectors.** The implementation is tested against RFC 9562 Appendix A:

| Vector                                    | Result                                                                      |
| ----------------------------------------- | --------------------------------------------------------------------------- |
| v1 `C232AB00-9414-11EC-B3C8-9F6BDECED846` | 2022-02-22T19:22:22.0000000Z, clock sequence 0x33C8, node 9F:6B:DE:CE:D8:46 |
| v6 `1EC9414C-232A-6B00-B3C8-9F6BDECED846` | The same timestamp, clock sequence and node                                 |
| v7 `017F22E2-79B0-7CC3-98C4-DC0C0C07398F` | 2022-02-22T19:22:22.000Z (0x017F22E279B0 ms)                                |
| v3, v4 and v5 examples                    | Versions 3, 4 and 5                                                         |

**Generation.**

- **v4:** `crypto.randomUUID()`, which gives 122 random bits.
- **v7:** layout `unix_ts_ms` (48) ‖ `ver` (4) ‖ `rand_a` (12) ‖ `var` (2) ‖ `rand_b` (62). Monotonicity follows §6.2 Method 1, a fixed-length dedicated counter:
  - The counter is 42 bits: all 12 bits of `rand_a` plus the leftmost 30 bits of `rand_b`.
  - On each new millisecond it is seeded with random bits, with its top bit cleared as a rollover guard. Within the same millisecond it increases by 1.
  - The last 32 bits of `rand_b` are fresh random bits for every UUID.
  - If the clock stands still or moves backwards during a batch, the previous timestamp is reused. A counter overflow (2⁴¹ UUIDs in one millisecond) would advance the timestamp by 1 ms.
  - So every batch is strictly increasing, both as bytes and as strings.
  - Monotonicity is guaranteed within one batch, not across separate requests.
- **Randomness:** the Web Crypto CSPRNG (`crypto.getRandomValues`).

**API.**

- **Count:** `count` is 1–1000.
- **Formats:** `format` is one of the five above.
- **Not idempotent:** `uuid_generate` returns new values on every call.