A Unix timestamp counts the number of seconds that have passed since 00:00:00 UTC on 1 January 1970, the "Unix epoch." It's how most databases, APIs, and log files store a moment in time, because it's a single unambiguous number rather than a date string that depends on timezone or format.
How it works
The converter takes the number you enter as seconds since the epoch and adds it to 1 January 1970 00:00:00 UTC.
The result is shown in ISO 8601 format (the standard most APIs expect), a human-readable UTC string, the equivalent value in milliseconds (what JavaScript's Date object uses internally), and the day of the week.
Everything here is calculated in UTC deliberately: converting to a viewer's local timezone would make the page render differently for every visitor and every server, which defeats the point of a timestamp being unambiguous.
A worked example
The timestamp 1735689600 converts to 2025-01-01T00:00:00.000Z, midnight UTC on New Year's Day 2025, which is also 1735689600000 in milliseconds, the format most JavaScript code expects.
Questions people ask
Why does my timestamp look 1,000× smaller than what my code expects?
Unix timestamps are defined in seconds, but JavaScript's Date.now() and many web APIs use milliseconds. If your number looks unusually small, multiply by 1,000; if it looks unusually large (13 digits instead of 10), it's already in milliseconds. Divide by 1,000 before using it here.
What happens after the year 2038?
Systems that store a Unix timestamp as a signed 32-bit integer will overflow on 19 January 2038, the so-called "Year 2038 problem." Most modern systems use 64-bit integers and aren't affected, but it's worth checking older infrastructure.
Can a Unix timestamp be negative?
Yes. A negative value represents a moment before 1 January 1970. Most systems support this, but some older or embedded systems don't.