API

A free timestamp API, with no key and no signup

Everything the converter does is also available as JSON. One GET, no account, no rate limit, and Access-Control-Allow-Origin: * so you can call it straight from the browser.

Quick start

curl https://parsetime.dev/api/t/1700000000

<value> is anything the converter accepts. URL-encode it if it contains characters like +. The response:

{
  "input": "1700000000",
  "detectedFormat": "Unix timestamp (seconds)",
  "hadExplicitZone": true,
  "note": null,
  "assumedZone": null,
  "iso": "2023-11-14T22:13:20.000Z",
  "unix": 1700000000,
  "unixMs": 1700000000000,
  "isoWeek": { "year": 2023, "week": 46 },
  "dayOfYear": 318,
  "utc": {
    "zone": "UTC",
    "formatted": "Tue, Nov 14, 2023, 10:13:20 PM",
    "offset": "GMT+00:00",
    "abbr": "UTC"
  },
  "zones": [
    {
      "zone": "Asia/Tokyo",
      "formatted": "Wed, Nov 15, 2023, 07:13:20 AM",
      "offset": "GMT+09:00",
      "abbr": "JST"
    }
  ]
}

Parameters

zonesdefaults to a default world clock
Comma-separated timezones, resolved as loosely as the converter's own “add a timezone” box. ?zones=tokyo,pst,Asia/Kolkata all work. Pass an empty ?zones= to get none. Anything that can't be resolved comes back in unresolvedZones, so it never fails the request.
tzdefaults to UTC
Which timezone an input that has no timezone of its own should be read as, e.g. ?tz=nyc. Ignored when the input already pins down an instant, so it never changes the meaning of a Unix timestamp or a value ending in Z.
formatdefaults to automatic detection
Decode the input as a specific encoding instead of guessing. The ids match the tool pages: discord-snowflake, twitter-snowflake, excel, ticks, ldap, webkit, objectid, uuid, cocoa, hex. Use it when the shape alone is ambiguous: a Discord snowflake and an epoch-nanoseconds value are both 19 digits. Input the named decoder can't read fails with 400 instead of falling back to guessing.

Try it

Cron schedules

The cron tool is also an endpoint: GET /api/cron?expr=… returns the expression explained in English plus its next run times.

curl "https://parsetime.dev/api/cron?expr=0+9+*+*+MON&tz=nyc&count=2&after=1700000000"

{
  "expression": "0 9 * * MON",
  "description": "At 09:00, on Monday.",
  "zone": "America/New_York",
  "runs": [
    { "iso": "2023-11-20T14:00:00.000Z", "unix": 1700488800 },
    { "iso": "2023-11-27T14:00:00.000Z", "unix": 1701093600 }
  ]
}

tz takes the same loose zone queries as everywhere else and defaults to UTC; count is 1–25 (default 5). Runs are computed from the moment of the request, so responses are not cached. Pass after (any absolute time) to pin the start and get an immutable, cacheable response.

Notes

Timezone-less input is read as UTC, not as the server's timezone. An input like 2026-06-01T09:00:00 names a wall clock, not an instant. The browser can reasonably assume it means your time; a server cannot, so this API assumes UTC and tells you so in assumedZone. Use tz to say otherwise.

Responses for a fixed instant are immutable. They carry a one-year Cache-Control, because a given timestamp's rendering never changes. The one exception is /api/t/now, which is never cached.

Match on offset, not on the zone name. Zone ids come back in whichever spelling the runtime considers canonical, and engines disagree; some resolve Asia/Kolkata to Asia/Calcutta. The offset is stable.

Errors are plain. Unparseable input, or a tz that cannot be resolved, returns 400 with an error and the input it was given.

Frequently asked questions

Do I need an API key?
No. There is no key, no signup, no account and no rate limit. Send a GET request and you get JSON back.
Can I call it from the browser?
Yes. Every response sends Access-Control-Allow-Origin: *, so it works from client-side JavaScript on any origin.
What formats does it accept?
Anything the converter accepts: Unix timestamps in seconds, milliseconds, microseconds or nanoseconds (the unit is inferred from magnitude), ISO 8601 with or without a timezone, RFC 2822, date-only values, loose text like "June 1 2026 3:00 pm", and the keyword "now". With ?format= it also decodes identifier encodings: Discord and Twitter snowflakes, Excel serial dates, .NET ticks, LDAP/FILETIME, WebKit/Chrome timestamps, MongoDB ObjectIds, UUIDs and ULIDs, Cocoa timestamps, and hex.
Why is there no relative time field?
Relative time depends on the moment of the request, so including it would make every response uncacheable for the sake of a value you can derive from the unix field yourself. Responses for a fixed instant are immutable instead.

Prefer a link to a page?

Every timestamp also has a shareable permalink, /t/1700000000 . It renders the same conversion as a page and unfurls as a preview card when pasted into Slack, Discord or a pull request.