# Resource IDs

Inspect a prefixed ULID and separate its timestamp from randomness.

MediaFilez resource IDs have a prefix, an underscore, and a lowercase [ULID](https://github.com/ulid/spec). 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.

```visual
resource-id
```

## 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.