The canonical spec for ulid
Alternatives To Spec
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
a month ago56gpl-3.0
The canonical spec for ulid
Ulid3,7021,0631,76619 days ago18June 22, 20223apache-2.0Go
Universally Unique Lexicographically Sortable Identifier (ULID) in Go
Ulid50713107 months ago16September 15, 20205apache-2.0Python
Universally Unique Lexicographically Sortable Identifier (ULID) in Python 3
Uniuri394236231a year ago1October 07, 20221cc0-1.0Go
Go package uniuri generates random strings good for use in URIs to identify unique objects.
Ulid3771316 months ago9March 01, 20211mitRuby
Universally Unique Lexicographically Sortable Identifier implementation for Ruby
Nulid241429 months ago11January 14, 20222mitC#
.Net ULID implementation
Python Ulid23743 days ago7March 10, 20222mitPython
ULID implementation for Python
Friendly Id182115 months ago9April 04, 20191apache-2.0Java
Java Friendly Id for UUID
9 months ago4PLpgSQL
Universally Unique Lexicographically Sortable Identifier (ULID) for PostgreSQL
310 years ago2March 24, 2015mitObjective-C
Convert UUID 32-character hex string into a Base32 short string and back.
Alternatives To Spec
Select To Compare

Alternative Project Comparisons


Universally Unique Lexicographically Sortable Identifier

UUID can be suboptimal for many use-cases because:

  • It isn't the most character efficient way of encoding 128 bits of randomness
  • UUID v1/v2 is impractical in many environments, as it requires access to a unique, stable MAC address
  • UUID v3/v5 requires a unique seed and produces randomly distributed IDs, which can cause fragmentation in many data structures
  • UUID v4 provides no other information than randomness which can cause fragmentation in many data structures

Instead, herein is proposed ULID:

  • 128-bit compatibility with UUID
  • 1.21e+24 unique ULIDs per millisecond
  • Lexicographically sortable!
  • Canonically encoded as a 26 character string, as opposed to the 36 character UUID
  • Uses Crockford's base32 for better efficiency and readability (5 bits per character)
  • Case insensitive
  • No special characters (URL safe)
  • Monotonic sort order (correctly detects and handles the same millisecond)

Implementations in other languages

From ourselves and the community!

Language Author Binary Implementation
C++ suyash
C# mcb2001
Clojure theikkila
Objective-C ricardopereira
Crystal SuperPaintman
Dart isoos
Dart GuepardoApps
Delphi matinusso
D enckse
D (dub) extrawurst
Erlang savonarola
Elixir Homepolish
Elixir merongivian
Elixir omisego
Elixir (Ecto) dcuddeback
F# lucasschejtman
Factor Alexander Ilin
Go oklog
Haskell steven777400
Java huxi
Java azam
Java Lewiscowles1986
JavaScript ulid
JavaScript aarondcohen
Julia ararslan
Kotlin GuepardoApps
Lua Tieske
.NET RobThree
.NET fvilers
Nim adelq
OCaml stripedpajamas
Perl 5 bk
PHP Lewiscowles1986
PHP robinvdvleuten
PowerShell PetterBomban
Python mdipierro
Python ahawker
Python mdomke
R hrbrmstr
Ruby rafaelsales
Rust mmacedoeu
Rust dylanhart
Scala petitviolet
SQL-Microsoft rmalayter
Swift simonwhitehouse
Swift yaslab
Tcl dbohdan


Below is the current specification of ULID as implemented in ulid/javascript.

Note: the binary format has not been implemented in JavaScript as of yet.

 01AN4Z07BY      79KA1307SR9X4MV3

|----------|    |----------------|
 Timestamp          Randomness
   48bits             80bits



  • 48 bit integer
  • UNIX-time in milliseconds
  • Won't run out of space 'til the year 10889 AD.


  • 80 bits
  • Cryptographically secure source of randomness, if possible


The left-most character must be sorted first, and the right-most character sorted last (lexical order). The default ASCII character set must be used. Within the same millisecond, sort order is not guaranteed

Canonical String Representation


t is Timestamp (10 characters)
r is Randomness (16 characters)


Crockford's Base32 is used as shown. This alphabet excludes the letters I, L, O, and U to avoid confusion and abuse.



When generating a ULID within the same millisecond, we can provide some guarantees regarding sort order. Namely, if the same millisecond is detected, the random component is incremented by 1 bit in the least significant bit position (with carrying). For example:

import { monotonicFactory } from 'ulid'

const ulid = monotonicFactory()

// Assume that these calls occur within the same millisecond

If, in the extremely unlikely event that, you manage to generate more than 280 ULIDs within the same millisecond, or cause the random component to overflow with less, the generation will fail.

import { monotonicFactory } from 'ulid'

const ulid = monotonicFactory()

// Assume that these calls occur within the same millisecond
ulid() // throw new Error()!

Overflow Errors when Parsing Base32 Strings

Technically, a 26-character Base32 encoded string can contain 130 bits of information, whereas a ULID must only contain 128 bits. Therefore, the largest valid ULID encoded in Base32 is 7ZZZZZZZZZZZZZZZZZZZZZZZZZ, which corresponds to an epoch time of 281474976710655 or 2 ^ 48 - 1.

Any attempt to decode or encode a ULID larger than this should be rejected by all implementations, to prevent overflow bugs.

Binary Layout and Byte Order

The components are encoded as 16 octets. Each component is encoded with the Most Significant Byte first (network byte order).

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|                      32_bit_uint_time_high                    |
|     16_bit_uint_time_low      |       16_bit_uint_random      |
|                       32_bit_uint_random                      |
|                       32_bit_uint_random                      |

Prior Art

Partly inspired by:

Popular Character Projects
Popular Uuid Projects
Popular Text Processing Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.