/public/tools/

UUID & ULID inspector

Paste a UUID or a ULID and this reads it back to you: which version and variant it is, and the creation timestamp embedded inside it for the kinds that carry one (UUID v1, v6, v7, and every ULID). When the identifier has no time to read — a v4 UUID is just random bits — it says so plainly instead of inventing a date. Everything decodes in your browser; the value you paste never leaves the page.

Accepts a UUID with or without hyphens, wrapped in braces, or as a urn:uuid: URN; and a 26-character Crockford base32 ULID.

What is actually inside one of these

A UUID is 128 bits, written as 32 hexadecimal digits in five hyphenated groups (8-4-4-4-12). Two small fields tell you how to read the other 122 bits: the version is the first nibble of the 7th byte (the digit after the second hyphen), and the variant is the top bits of the 9th byte (the digit after the third hyphen). The version says how the value was generated; the variant says which standard's layout it follows. A ULID is a different thing wearing similar clothes: 128 bits encoded as 26 Crockford base32 characters, with no hyphens and no version field, where the first 48 bits are always a millisecond timestamp.

Only some versions carry a timestamp

This is the whole reason the tool exists. People reach for a UUID hoping to learn when a row was created, and whether that question has an answer depends entirely on the version. A v1 or v6 UUID encodes a 60-bit count of 100-nanosecond ticks since 1582; a v7 UUID and every ULID start with a plain Unix millisecond timestamp. But v4 — by far the most common UUID in the wild — is 122 bits of randomness with no time in it at all, and v3/v5 are hashes of a name. For those there is no creation time to recover, and any tool that shows you one is lying. This one shows you nothing, and tells you why.

Sortable is not the same as time-bearing

A v7 UUID, a v6 UUID, and a ULID all put their timestamp in the high bits, so sorting them as strings sorts them by creation time — which is why they make good database keys. A v1 UUID also contains a timestamp, but it scatters the time across scrambled fields, so it is not lexically sortable; v6 exists precisely as the sortable reordering of v1. A v4 UUID is neither time-bearing nor sortable. If you are choosing an identifier for a new table and you want time-ordered keys, that is the distinction that matters.

What this tool does not do

It reads the bits in front of it and nothing else. It cannot tell you which machine minted a v1 UUID's node field, whether a v8 UUID's custom layout hides a timestamp (the spec leaves that to the vendor), or whether two ids actually came from the same generator. It treats the variant honestly: if the variant bits are not the RFC 9562 layout, the version nibble may not mean what the standard says, and the tool flags that rather than guessing.

Version reference

Single static HTML file, no network. The identifier you paste never leaves the browser. Source: github.com/truffle-dev/tool-id-inspector. MIT.