UUID / ULID Generator & Validator — Free HTML CSS JS Snippet

Both UUIDs and ULIDs solve the same underlying problem — generating an identifier unique enough to assign without checking a central database — but they trade off differently between randomness and sortability. This snippet generates both formats correctly, using real cryptographic randomness from the Web Crypto API rather than Math.random(), and includes a validator that recognizes and decodes both.

UUID v4: 122 bits of real entropy, RFC 4122 formatted

genUuid4() prefers the browser's native crypto.randomUUID() when available, which is the most correct implementation possible — it's provided directly by the browser's cryptographic subsystem. As a fallback for older environments, the function generates 16 random bytes via crypto.getRandomValues() (a cryptographically secure random number generator, unlike Math.random() which is not specified to be unpredictable), then manually sets the two fixed bit patterns RFC 4122 requires: byte 6 is masked to 0x40 in its top nibble to encode "version 4," and byte 8 is masked to 0x80/0xa0-range to encode the "variant" bits. Only 122 of the 128 bits are actually random — the other 6 are fixed by the version and variant markers — which is why UUID v4 collision probability calculations use 122, not 128, bits of entropy.

ULID: sortable by design, using Crockford's Base32

A ULID (Universally Unique Lexicographically Sortable Identifier) deliberately encodes the current timestamp into its first 48 bits (10 characters), followed by 80 bits (16 characters) of randomness — 26 characters total. Because the timestamp comes first and is encoded in a way that preserves ordering, ULIDs generated later always sort after ULIDs generated earlier when compared as plain strings, which a random UUID cannot do. genUlid() builds the 48-bit millisecond timestamp as 6 raw bytes, then encodes both the timestamp bytes and 10 additional random bytes through encodeCrockford(), which converts the bit string 5 bits at a time into Crockford's Base32 alphabet — a 32-character set (0-9, most letters, deliberately excluding I, L, O, and U to avoid visual confusion with 1, 0, and profanity) chosen specifically for human readability and reduced transcription errors versus standard Base64.

Why 5-bit chunks, not the usual base64's 6-bit chunks

Base32 uses a 32-symbol alphabet, and 32 = 2^5, so each output character encodes exactly 5 bits of input — that's why encodeCrockford() walks the bit string in slices of 5 (bits.slice(i, i + 5)) rather than the 6-bit slices you'd use for standard Base64's 64-symbol alphabet. 128 bits total (48 timestamp + 80 random) divided by 5 bits per character comes out to 25.6, which is why the timestamp portion is deliberately truncated to exactly 10 Crockford characters (50 bits' worth of capacity holding a 48-bit value, zero-padded) and the combined string is sliced to exactly 26 characters in the final step.

Validating and decoding both formats

The validator applies a strict regex for each format — the UUID pattern specifically checks for a version digit (1-5) in the expected position and a variant nibble (8, 9, a, or b) in the next group, rather than accepting any 32 hex characters in UUID-shaped groups, which would also match non-compliant "UUID-like" strings. For a recognized ULID, the validator goes further: it decodes the first 10 characters back through the Crockford alphabet into their original 48-bit value and renders it as an ISO date, letting you extract the exact creation timestamp embedded in any ULID you paste in — a capability that has no UUID v4 equivalent, since a v4 UUID intentionally carries no information about when it was created.