Date & Time

Unix Timestamp Converter

Converts epoch and ISO timestamps into readable dates, in bulk, with the timezone spelled out.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste your timestamps, one per line. Epoch numbers and ISO strings can be mixed freely.
  2. Pick the timezone you want the readable column shown in.
  3. Leave the unit on automatic unless your numbers are unusual — the size of the number normally settles it.
  4. Select Convert, and check the ISO column against the relative column to be sure the unit was read as you expected.

What timestamp converter does

A timestamp in a log is a number, and the number alone does not tell you whether it is seconds or milliseconds. This page decides from the magnitude — anything past about the year 5138 in seconds is really milliseconds, and past that again is microseconds — and says which reading it used, so a value pasted from Postgres, from Java and from a shell script all land on the right minute rather than three centuries apart.

Paste a whole column and every line is converted at once, into ISO 8601 in UTC, into the zone you pick, back into epoch seconds and milliseconds, and into plain relative English. The relative column is the one that answers the question people usually have, which is not what time it was but how long ago that was.

Frequently asked questions

By size. A ten-digit epoch in seconds is a date in the current era; the same digits read as milliseconds would be in 1970. Anything at eleven digits or more is treated as milliseconds, and at fourteen or more as microseconds. The row says which reading it used, and you can force one if your data is unusual.

No. The conversion is arithmetic and a call to your browser’s own Intl implementation, both on the page. That matters more than it sounds: timestamps usually arrive pasted out of a production log, alongside identifiers that were never meant to leave the building.

It is read in the zone you selected, and the row says so. A bare "2026-03-04 09:15" has no timezone information at all, so something has to be assumed — the only wrong approach is assuming silently.

Usually because the database column is a timestamp without a timezone and is being displayed in the session timezone rather than UTC. Compare the ISO column here with the value your database gives when you explicitly cast to UTC, and the discrepancy normally resolves into a session setting.