Identifier inspection
ULID timestamps: Crockford encoding, ordering and privacy
A ULID contains a 48-bit Unix-millisecond timestamp and an 80-bit tail. Reading those fields helps debug logs and primary keys, but it does not establish where an identifier came from or when a real record was created.
Content updated: · Maintained by Hung Chi-Hsueh · corrections
Use the ULID alphabet, not a generic Base32 decoder
The canonical ULID specification uses 26 ASCII characters from 0123456789ABCDEFGHJKMNPQRSTVWXYZ. This tool accepts ASCII lowercase and emits uppercase, but rejects I, L, O and U rather than mapping aliases. RFC 4648 Base32 and base32hex use different alphabets and padding conventions; the site's Base32 codec intentionally does not guess Crockford encoding.
Only outer ASCII spaces and tabs are ignored per line. Quotes, braces, URNs, Unicode lookalikes and invisible characters are rejected. Error positions refer to the original line and identify invalid characters by code point. The original input is kept unchanged, including failed rows.
130 encoded bits represent only 128 data bits
Twenty-six five-bit symbols provide 130 encoded bits. The leading two bits must be zero, so the first character is restricted to 0–7. The first ten characters carry 48 timestamp bits, not 50 time bits. A value starting with 8 exceeds the 128-bit range and is rejected without truncation.
The 16-byte diagram uses big-endian order: bits 0–47 are time and bits 48–127 are the tail. The maximum legal value is 7 followed by 25 Z characters, encoding 281474976710655 milliseconds and UTC +010889-08-02T05:31:50.655Z. All zeroes encode Unix epoch zero; ULIDs have no UUID Nil interpretation here. BigInt preserves all 128 bits; report integers are decimal strings or Hex, not rounded JSON numbers.
Encoded time and lexical order are not creation evidence
The time field is unsigned Unix milliseconds. Valid future dates, including expanded ISO years, are accepted. Local time uses the browser's time zone and the offset at that instant; UTC and milliseconds remain the reproducible reference. A clock can be wrong, reset or deliberately chosen, so decoded time is not an audit trail.
Canonical uppercase ULIDs sort by time using ASCII lexical order. Within one millisecond the tail does not guarantee creation order; a monotonic generator can increment it, but independent generators still do not establish a global order. The tail's shape cannot prove secure randomness, entropy or uniqueness. ULIDs are identifiers, not bearer secrets or authorization.
Review the whole batch before exporting private identifiers
The input limit is 128 KiB UTF-8 and 1,000 nonblank rows. Blank lines are counted, original physical line numbers and order are preserved, and duplicate counts use decoded canonical values. Invalid rows remain beside valid rows. The list and report preview show at most 50 rows; complete JSON copy and download include every nonblank original row and its result or error. The full report limit is 2 MiB. Whole-batch limit failures clear results rather than exporting a partial batch.
Inputs stay in page memory: no uploads, persistence, input URLs or tool analytics. Reports contain original identifiers and can link records across services, so review before sharing; decoding and downloading do not anonymize data. Clearing the page does not erase the clipboard or downloaded files and is not a secure memory-erasure guarantee. Modern browsers with BigInt, TextEncoder and native local-download support are required; there is no remote fallback.
01ARZ3NDEKTSV4RRFFQ69G5FAV
Unix milliseconds: 1469922850259
UTC: 2016-07-30T23:54:10.259Z
Tail Hex: d6764c61efb99302bd5b
00000000000000000000000000: Unix epoch zero
80000000000000000000000000: overflow (rejected)
O0000000000000000000000000: invalid alphabet (rejected)Data provenance