Resource IDs
Inspect a prefixed ULID and separate its timestamp from randomness.
MediaFilez resource IDs have a prefix, an underscore, and a lowercase ULID. For example, job_ identifies a job. Keep the full ID as a string and pass it back to the API unchanged.
Inspect an ID
The example below runs locally. Paste a resource ID to inspect its layout, timestamp, and bits. It makes no API request.
Purple marks the timestamp; orange marks the random part. The arrows convert only the timestamp into milliseconds, then a UTC date. The binary digits are grouped in bytes for readability, and each label names the field's bit range.
00000001010101100011111000111010101101011101001148-bit timestamp
Milliseconds since the Unix epoch1101011001110110010011000110000111101111101110011001001100000010101111010101101180 bits of randomness
Random value for uniquenessThe 26 Base32 characters encode 128 bits. Two leading padding bits are omitted above.
The timestamp is milliseconds since 1970-01-01 UTC.
Layout
| Part | Meaning |
|---|---|
| Prefix | Resource type, such as job, fil, bat, pl, or pli |
| First 10 ULID characters | 48-bit Unix timestamp in milliseconds |
| Last 16 ULID characters | 80 bits of randomness |
The ULID portion contains 128 bits encoded in 26 Crockford Base32 characters. The encoding has two leading padding bits, so a valid first character is 0 through 7.
Time is measured from the Unix epoch, not Discord's custom epoch. The resource prefix is not part of the ULID value.
What the timestamp does not tell you
It describes the ID's timestamp, not when a download completed, when a file expires, or who owns it. Use the API's timestamps and ownership checks for those questions. A syntactically valid ID does not prove a resource exists.
This is different from Discord user IDs, which are Snowflake strings. It is also different from API-key secrets beginning with mf_; do not paste credentials into examples or reports.