A canonical ULID is 26 Crockford Base32 characters where the first 10 characters encode Unix milliseconds and the final 16 encode 80 bits of randomness, so anyone holding the string can read the embedded millisecond timestamp without a network request or a server-side dependency. This makes the "decode ULID timestamp API alternative" question practical: developers who only need to extract creation time from an existing identifier can skip the HTTP round-trip and run the conversion in the browser. The ULID Generator tool offers both directions in one place — generate monotonic ULID batches from cryptographic randomness, and decode any canonical 26-character string back into its millisecond and ISO UTC instant. Because generation, decoding, formatting, and copying happen entirely in the browser, no identifier or timestamp is uploaded, and the page stays usable even on an offline machine. The local path is not a replacement for production libraries inside a runtime, but it is the cleanest way to satisfy a one-off decode without spinning up an endpoint.
When a Browser Tool Replaces the Decode Endpoint
Most public ULID libraries expose a decodeTime function or a small REST endpoint that returns the embedded Unix milliseconds plus the ISO instant. For production code that already runs in Node, Deno, or Bun, calling decodeTime from a package such as the JavaScript reference implementation or reading the rules in the canonical ULID specification is the right path. The browser-only path makes sense in three situations: a support engineer reading a customer-supplied ULID from a log file, a developer doing an offline review of generated IDs, or a reviewer auditing IDs that should never leave the machine. In all three cases the goal is the same — turn 26 characters into a readable timestamp without firing an HTTP request or paying the latency of a remote lookup.
The ULID Generator handles both directions in a single page: Generate creates a monotonic batch from cryptographic randomness, and Decode reads the timestamp and ISO UTC instant from any canonical string. Because every step runs locally, the page never receives a copy of your identifiers, which is a meaningful improvement when you are reviewing records that link to private data. The page also keeps its initial render deterministic — Date.now is read only inside the Generate click handler, not during server rendering — so refreshing the tab does not leak clock values into the static layout.
Anatomy of the 26-Character String
A canonical ULID is fixed at 26 characters drawn from the Crockford Base32 alphabet, which excludes I, L, O, and U to reduce visual ambiguity. The split is exactly 10 plus 16: the first 10 characters encode 48 bits of Unix time in milliseconds, and the final 16 characters encode 80 bits of randomness. The alphabet is fixed by the spec, and any character outside it makes the string invalid even if the length is correct.
| Position | Character count | Field | Range / size | Notes |
|---|---|---|---|---|
| 1–10 | 10 | Unix milliseconds | 0 to 281,474,976,710,655 | 48-bit unsigned; the maximum canonical string therefore begins with 7 |
| 11–26 | 16 | Cryptographic randomness | 80 bits per ID, incremented within a batch | Rejected on overflow instead of wrapping |
| Alphabet | — | Crockford Base32 | 32 symbols, omits I, L, O, U | Decoding is case-insensitive but output is canonical uppercase |
The 48-bit time field is what makes the identifier sortable in ASCII lexical order — for strings of the same length, a larger left-hand integer is also a larger character sequence. That property is the reason most teams reach for ULIDs over UUID v4 for ordered primary keys, log indexes, and event-time correlation. The same property is also the reason a decode operation can return a meaningful timestamp from the string alone, with no out-of-band metadata.
Decode a ULID Timestamp Locally
Working through an existing identifier with the Decode panel is the canonical reader workflow. The tool accepts any 26-character canonical string after Crockford normalization and returns both the raw millisecond count and the equivalent ISO UTC instant.
- Open the ULID Generator page and switch the mode to Decode.
- Paste the canonical 26-character ULID into the input field; the alphabet is checked after case normalization.
- Read the millisecond value and the matching UTC timestamp rendered as ISO 8601.
- If you need the value as a SQL-friendly Unix second or want to compare it against another timestamp, hand the milliseconds to the Unix timestamp SQL guide for the exact conversion rule in your dialect.
Reject cases are worth knowing up front. A 26-character value that begins with 8 or above contains more than 128 bits and is rejected, because the spec reserves only 128 bits total. Strings with letters outside Crockford Base32 also fail — for example a lowercase u is not part of the alphabet and will not be normalized to v. The tool keeps the validation strict so that what you read back always matches what was encoded. A displayed ISO time is rendered as UTC, while a local calendar view of the same millisecond can land on a different date in your time zone.
Generate a Monotonic Batch Locally
Generation follows a stricter contract than decoding. Each click captures one Date.now value, encodes it into the 10-character time field, asks the browser cryptographic random source for 80 bits, and then increments that random region by one for every subsequent ID in the same batch — including the carry that propagates across the full 16-character random suffix.
- Open the ULID Generator and leave the mode on Generate.
- Pick a quantity between 1 and 100. Values outside that range are not accepted.
- Click Generate once. The whole batch shares the captured millisecond, with each ID strictly greater than the previous one in ASCII order.
- Copy the full 26-character identifiers and store them in a case-preserving column. Add a unique constraint on the column so the database, not the tool, becomes the final arbiter of uniqueness.
If the 80-bit random field would overflow inside the batch, generation fails rather than wrapping — a deliberate choice that keeps the returned strings strictly increasing. The tool also refuses to coordinate with other tabs, devices, services, or previously generated values, so do not rely on it to settle uniqueness across a distributed system. Treat the click as a source of local entropy plus a captured millisecond, nothing more.
Limits and Storage Rules That Matter
The tool draws a hard line at the spec's 128-bit total budget. The 48-bit timestamp can therefore represent from 0 up through 281,474,976,710,655 milliseconds, and the maximum canonical string begins with 7. Anything that would need a leading 8 or higher contains a bit pattern outside the spec and is rejected on both Generate and Decode paths. Lexical sorting only holds for the canonical 26-character representation under ordinary bytewise or ASCII-compatible collation — case-folding, locale collation, truncation, padding, or storage in an undersized column all break the intended order, so always test the exact database collation before promoting ULIDs to a primary key.
The visible timestamp and random suffix do not protect a record from enumeration or disclosure when access control is missing. A ULID is not a password, API key, bearer token, authorization rule, or encryption key, and the left-hand time field intentionally exposes approximate creation time. Avoid logging ULIDs when they link to personal or confidential records, and use the platform's dedicated credential system for anything that needs to stay secret. A short ULID column or a case-insensitive collation will silently corrupt ordering the moment the index fills up.
Browser Tool vs Hosted Decode Endpoint
| Concern | Local browser tool | Hosted decode endpoint |
|---|---|---|
| Network round-trip | None — runs in the same tab | HTTP request per decode |
| Identifier leaves the machine | No identifier or timestamp is uploaded | Depends on the provider's policy |
| Offline usability | Works once the page is loaded | Requires connectivity |
| Validation strictness | Enforces the 128-bit cap and Crockford alphabet | Varies by implementation |
| Bulk throughput | Generate produces up to 100 IDs per click | Rate-limited by the host |
| Cross-system coordination | Cannot coordinate with other tabs or services | Can share state across callers |
The local workflow wins on privacy and offline use, and it stays deterministic because Date.now is only read inside the Generate click handler rather than during server rendering. The hosted endpoint still wins when many services need to coordinate uniqueness, so for production backends keep a real ULID library in the runtime and reach for the browser tool when you need a fast, offline read. Eight external fixtures lock the boundary values — zero, the Base32 edges, one second, the reference decodeTime example, and the maximum timestamp — so the constants you read here match the constants the spec enforces.
Practical Checklist Before You Ship
Three rules remove most of the friction people hit when they move from UUIDs to ULIDs. First, keep the full uppercase string and store it in a case-preserving 26-character field — never truncate to fewer characters and never strip the leading characters thinking they are predictable. Second, enforce a database unique constraint and handle the conflict atomically; randomness reduces collision probability but never replaces a uniqueness guarantee, and a check-then-insert race is never an acceptable final control. Third, treat the decoded time as metadata rather than authenticated truth — it is useful for ordered indexes, log correlation, and rough creation-time estimation, but it does not prove that a particular actor created the record at that instant.
When the question is "decode ULID timestamp API alternative," the honest answer is that the alternative is not a different specification — it is the same Crockford Base32 encoding read in your browser instead of over HTTP. That single shift is enough to cover support reviews, offline audits, and one-off lookups without adding an external dependency to your stack. For high-volume code paths, drop back into a library that matches your runtime; for the occasional decode, stay local and keep the identifiers on your machine.
For a deeper look, see Convert Unix Timestamp to Date in JavaScript.