Both encode a 48-bit millisecond timestamp plus randomness. UUID v7 is an RFC 9562 standard and fits native UUID columns; ULID's base32 text form is shorter and more readable. Choose by which format your stack expects.

Yes — lexicographic order of the text form matches chronological order, because the timestamp occupies the leading bits and base32 preserves ordering.

Can someone tell when a record was created?

Yes. The timestamp is recoverable from the ID by design. Use a fully random identifier if creation time is sensitive.

What happens if two ULIDs are generated in the same millisecond?

The random component distinguishes them. A monotonic generator increments it so ordering stays strict within one process; across processes the order within that millisecond is arbitrary.

Security🔒 Browser (client-side)API available📴 Works offlinebeginner

ULID Generator

Generates and parses Universally Unique Lexicographically Sortable Identifiers (ULID) with millisecond-precision timestamps and random entropy.

Data stays in your browser

Ready to runInstant execution

All tools →

Result

—

What does this tool do?

Generates and parses Universally Unique Lexicographically Sortable Identifiers (ULID) with millisecond-precision timestamps and random entropy.

Why would I use it?

You need unique IDs that sort chronologically in databases without auto-increment bottlenecks.
You want 128-bit security compatible with UUID without punctuation hyphens.
You are indexing high-concurrency event logs, time-series events, or microservices.

Real-life example

Input

Count: 1

Output

01ARZ3NDEKTSV4RRFFQ69G5FAV (Timestamp: 2026-08-16T20:30:00.000Z)

First 10 characters encode timestamp, last 16 encode randomness.

Input → Process → Output → Next

Input: Specify count of ULIDs to generate or paste an existing ULID to parse.
Process: Computes Crockford Base32 48-bit timestamp and 80-bit CSPRNG entropy.
Output: Sortable 26-character alphanumeric string or parsed ISO timestamp.
Next action: Use as database primary key in PostgreSQL, MySQL, or distributed stores.

Common mistakes

Assuming ULIDs can be generated out-of-order and remain strictly sorted (monotonically dependent).
Confusing Crockford Base32 with standard Base64 (Crockford excludes I, L, O, U to avoid visual ambiguity).
Truncating the 26-character string.

What the result means

A 128-bit collision-resistant identifier ordered chronologically by millisecond.

Privacy & security

Your input is processed entirely in your browser and never sent to a YAS server.

API

Endpoint

POST https://yas.sh/api/v1/tools/ulid-generator

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/ulid-generator" \
  -H "Content-Type: application/json" \
  -d '{"count":1}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/ulid-generator", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "count": 1
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/ulid-generator", json={"count":1})
data = r.json()

Field	Type	Required	Description
count	integer	No (default 1)	Count to generate (1–50)
input	string	No	Optional ULID string to parse

Success response

{ "slug": "ulid-generator", "count": 1, "result": "01ARZ3NDEKTSV4RRFFQ69G5FAV" }

Generate sortable 128-bit ULIDs or parse timestamp.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How ULID Generator works

A ULID is 128 bits: a 48-bit millisecond timestamp followed by 80 bits of randomness, rendered as 26 characters in Crockford base32. That encoding excludes I, L, O and U to avoid visual and transcription ambiguity, and the timestamp occupies the leading characters — so lexicographic sorting of the text form matches chronological order, which is the property that makes ULIDs useful as keys.

Within the same millisecond, monotonic implementations increment the random component rather than redrawing it, guaranteeing strictly increasing values in a single process. Across processes there is no coordination, so two nodes generating in the same millisecond produce values whose relative order is arbitrary — ULIDs give you approximate global ordering, not a distributed sequence.

When to use it: real-world scenarios

Primary keys that sort by creation time

New rows append to the end of the index rather than scattering, which avoids the page splits and write amplification random keys cause on large tables.

Log and event identifiers

Sorting by ID sorts by time, so range scans over a time window need no separate timestamp index.

Distributed generation without coordination

Multiple services can mint IDs independently and still produce a roughly time-ordered global sequence.

Identifiers people occasionally read aloud

Crockford base32 omits the characters most often confused in transcription, which measurably reduces support errors.

Pro tips

ULIDs leak creation time by design. If that is sensitive — exposing signup order or record volume — use a random identifier instead.
Store as 16 bytes rather than 26 characters where the database supports it; the text form more than doubles the storage and slows comparisons.
Use a monotonic generator if you create many IDs within a millisecond in one process, or ordering within that millisecond is arbitrary.
UUID v7 offers the same time-ordering in the standard UUID format. Prefer it where tooling expects a UUID type.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

The embedded timestamp discloses when the record was created and, in aggregate, how fast records are being created.
Monotonicity holds within a single generator, not across processes or hosts.
The 26-character form is longer than NanoID for user-facing use.
ULID is a community specification rather than an RFC, so support varies by ecosystem.

Frequently asked questions

ULID or UUID v7?: Both encode a 48-bit millisecond timestamp plus randomness. UUID v7 is an RFC 9562 standard and fits native UUID columns; ULID's base32 text form is shorter and more readable. Choose by which format your stack expects.
Are ULIDs sortable?: Yes — lexicographic order of the text form matches chronological order, because the timestamp occupies the leading bits and base32 preserves ordering.
Can someone tell when a record was created?: Yes. The timestamp is recoverable from the ID by design. Use a fully random identifier if creation time is sensitive.
What happens if two ULIDs are generated in the same millisecond?: The random component distinguishes them. A monotonic generator increments it so ordering stays strict within one process; across processes the order within that millisecond is arbitrary.