UUID / ULID / NanoID / Snowflake

Generate 1–500 identifiers per batch; copy every line or inspect the first ID. Generation starts only on request. UUID v4/v7 and NanoID use browser cryptographic randomness. UUID v7 carries a 48-bit millisecond timestamp but is not monotonic within a millisecond.

ULIDs retain the last timestamp when the clock rolls back and increment their 80-bit field for repeated timestamps. Field exhaustion is an error, never a random restart. Parsing rejects values above 128 bits, including first characters above 7.

NanoID length is 1–64 Unicode code points. Custom alphabets contain 2–256 distinct printable code points; whitespace, controls and lone surrogates are rejected. Rejection sampling avoids modulo bias. Unicode alphabets are a code-point extension; graphemes are not normalized. Small alphabets or short lengths can repeat; batch duplicates are reported without silently deleting them.

Snowflake uses a generic 63-bit layout: 41 timestamp bits, 10 combined node bits and 12 sequence bits. Twitter/Discord select the epoch only; this does not identify a provider. A node can issue 4,096 sequence values per millisecond in this page. Clock rollback or exhaustion produces an error. Instances on other pages or machines are not coordinated. This is not Sonyflake.

Inspection reports compatible shapes, not proven origin or randomness. Automatic interpretation prefers UUID, ULID, Snowflake, then text; use the selector to resolve ambiguity. UUID accepts canonical, compact, outer-braced and urn:uuid: forms, with timestamps for RFC-variant v1/v6/v7 and Nil/Max special values. Snowflake requires an explicit epoch; dates outside the browser range are labelled. NanoID-like text has no inferable entropy or timestamp.

IDs and settings stay only in page memory across tool switches; nothing is saved in cookies/browser storage or uploaded, and reload clears them. References: UUID, ULID, NanoID, Snowflake layout.