Inspectors

Unix Timestamp Converter

Convert between Unix timestamps and human-readable dates.

Input
TIMESTAMP input
Output
Result
Options

Further reading

  • How to convert a Unix timestampConvert Unix timestamps correctly: seconds versus milliseconds, UTC versus local time, the 2038 problem, leap seconds and why timestamps beat date strings.

About this tool

A Unix timestamp counts the seconds elapsed since 1 January 1970 UTC. It is the standard way to store an instant because it is unambiguous (no timezone, no locale, no formatting), but it is unreadable to people, which is why this conversion comes up constantly when reading logs and database rows.

The conversion works in both directions and reports every representation at once: seconds, milliseconds, ISO 8601, RFC 2822, UTC, your local time, and how long ago it was.

How to use it

  1. Paste or upload your timestampDrop a file onto the input pane, use the file picker, or paste the text directly.
  2. Adjust the options if neededThe defaults suit most input; open Options to change the behaviour.
  3. ConvertPress Convert, or use Ctrl+Enter (Cmd+Enter on macOS).
  4. Copy or downloadCopy the result, or download it as a .txt file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

A timestamp in seconds

Input

1700000000

Output

Interpreted input as: seconds since the Unix epoch

Unix seconds:       1700000000
Unix milliseconds:  1700000000000
ISO 8601 (UTC):     2023-11-14T22:13:20.000Z
RFC 2822:           Tue, 14 Nov 2023 22:13:20 GMT

Ten digits, so it is read as seconds. Output is truncated here; the tool also shows local time and a relative description.

A date converted back

Input

2023-11-14T22:13:20Z

Output

Interpreted input as: date string

Unix seconds:       1700000000
Unix milliseconds:  1700000000000
ISO 8601 (UTC):     2023-11-14T22:13:20.000Z

Any date string JavaScript can parse works, including ISO 8601 and RFC 2822.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Seconds or milliseconds, detected by magnitude
Unix time is defined in seconds, but JavaScript, Java and many APIs use milliseconds, and mixing them is the most common timestamp bug. A millisecond value read as seconds lands tens of thousands of years in the future; a seconds value read as milliseconds lands near January 1970. A 10-digit value is seconds and a 13-digit value is milliseconds, so magnitude is a reliable signal. You can override the detection if your value is genuinely ambiguous.
UTC versus local time
The timestamp itself carries no timezone; it is always an instant in UTC. Both the UTC rendering and your browser's local rendering are shown, because the difference is where timezone bugs live. If you need a specific zone other than your own, convert to UTC and offset from there.
ISO 8601 is the right interchange format
The ISO form (2023-11-14T22:13:20.000Z) sorts correctly as text, is unambiguous about its offset, and is parsed by every modern language. The trailing Z means UTC. Prefer it over locale-dependent formats for anything crossing a system boundary.
Range and precision limits
JavaScript dates span roughly ±8.64 × 10^15 milliseconds around 1970, about ±273,000 years, and values beyond that are rejected. Note also the 2038 problem: systems storing Unix time in a signed 32-bit integer overflow on 19 January 2038, which is why 64-bit storage matters for future dates.
Leap seconds are not represented
Unix time deliberately ignores leap seconds, treating every day as exactly 86,400 seconds. It is therefore not a true count of elapsed SI seconds, and sub-second accuracy across a leap second is not something this or any Unix timestamp can express.

Limitations

  • Shows UTC and your browser's local timezone only, not arbitrary zones.
  • Leap seconds are not represented, as Unix time excludes them by definition.
  • Dates beyond roughly ±273,000 years from 1970 cannot be represented.
  • Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

How do I know if my timestamp is in seconds or milliseconds?
Near the present, ten digits suggests seconds and thirteen suggests milliseconds. A date near January 1970 means seconds were read as milliseconds; a date thousands of years ahead means milliseconds were read as seconds. Auto mode actually uses an absolute-value threshold above 100,000,000,000 for milliseconds, so override the unit for ambiguous historical or far-future input.
Why does the local time differ from the UTC time?
The timestamp is an instant in UTC. Your local rendering applies your browser's timezone and daylight saving rules, so the wall-clock time differs by your offset.
What is the 2038 problem?
A signed 32-bit integer cannot hold Unix seconds past 19 January 2038, so such systems overflow to a negative value and jump to 1901. Storing timestamps in 64 bits avoids it.
Can I convert to a specific timezone?
The tool shows UTC and your local time. For another zone, take the UTC value and apply that zone's offset, remembering that daylight saving changes the offset by date.

Related tools