Timestamp Converter
Convert Unix Timestamps to readable dates and vice versa.
Converted Result
About Unix Timestamp Converter
Unix time counts the seconds elapsed since midnight UTC on 1 January 1970. It is a single integer with no zone, no locale and no formatting attached, which is exactly why databases, log files and API payloads prefer it — and exactly why it is unreadable at a glance. Type a value into the seconds field above and it is rendered three ways at once.
Seconds, milliseconds, and the mistake everyone makes
The field on this page expects seconds. Nothing in a bare integer records its unit, so a millisecond value is not rejected — it is faithfully converted into a date tens of thousands of years from now. Count the digits before you paste: ten is seconds through the 2030s, thirteen is milliseconds, sixteen is microseconds. Getting this wrong in production is how a cache entry ends up valid for a millennium or a token expires the instant it is issued.
Which output belongs where
Use the ISO 8601 row for anything a machine will read back — it is unambiguous, sorts correctly as a string, and is what JSON.stringify produces for a Date. Use the row labelled RFC 2822, the one ending in GMT, when you are writing an HTTP header. Use the Local row only for reading, never for storage: it is formatted for your device's region, so the same instant reads as 03/04 in one country and 04/03 in another.
Where this comes up
The usual jobs are reading an exp or iat claim out of a decoded JSON Web Token, lining a log entry up with an incident window, checking what a created_at integer column actually holds, working out whether a signed URL has expired, and generating a fixed timestamp for a test fixture. The live counter at the top of the page exists for that last case.
Limits worth knowing
Every conversion is arithmetic on your device — the page makes no request, so the values you paste are never transmitted and the tool works offline. Two things it does not do: there is no time zone selector, so to see an instant in a zone other than yours, read the UTC row and offset it yourself; and leap seconds are ignored, as they are in Unix time generally, since the count deliberately pretends every day has exactly 86,400 seconds. To decode a token before converting its claims, the JWT Decoder is the companion tool.
Both Directions, Same Screen
Type an epoch value on the left and the three rendered forms follow it; pick a calendar date on the right and the epoch field is filled in to match. The picker does not track edits made to the number, so it stays where you last set it.
A Clock You Can Copy From
The panel at the top ticks once a second with the current epoch value, which saves opening a console just to find out what time it is in integer form.
Three Renderings At Once
Local time for reading, ISO 8601 in UTC for storing and sending, and the row labelled RFC 2822, which is the GMT string HTTP headers use — shown together so the offset between them is visible.
Frequently Asked Questions
I pasted my timestamp and got a date in the year 57571. What happened?
You pasted milliseconds into a field that expects seconds. JavaScript's Date.now, Java's System.currentTimeMillis and most JSON APIs report milliseconds, while Unix time, PostgreSQL's extract(epoch), Go's Unix() and JWT claims use seconds. The giveaway is length: a current value in seconds has ten digits, one in milliseconds has thirteen. Drop the last three digits and try again. A sixteen-digit value is microseconds, common in ClickHouse and some tracing systems, so drop six.
Why do the three result rows disagree?
They are the same instant written three ways. Local uses your operating system's time zone and locale formatting, so it is what a person in your chair would recognise. ISO 8601 is always UTC and ends in Z, which is the form to put in an API payload or a log line. The third row is the GMT string used in HTTP headers such as Expires and Last-Modified. If Local and ISO differ by a whole number of hours, that difference is your UTC offset.
Does the 2038 problem affect this page?
No. That limit comes from C's 32-bit signed time_t, which overflows in January 2038, and it still matters for embedded systems and old database columns. JavaScript stores time as a double-precision number of milliseconds, and the language caps valid dates at 8.64e15 milliseconds either side of 1970 — roughly 273,790 years. In this seconds field anything up to 8,640,000,000,000 converts; beyond that you get Invalid Date rather than a wrong answer.
How do I convert a date back into a timestamp?
Use the Date & Time picker on the right and the seconds field updates to match. Two caveats. The picker interprets what you choose in your local zone, not UTC, so the number reflects your offset — check the ISO row to confirm you got the instant you meant. And the browser's picker usually offers only hours and minutes, so seconds land on zero.
Can I enter a date before 1970?
Yes, as a negative number of seconds. -1000000000 resolves to April 1938, and the ISO and GMT rows render it correctly. Historical dates carry a caveat that has nothing to do with this tool: the further back you go, the less the arithmetic corresponds to what a calendar of the time actually said, because time zones, daylight saving rules and the Gregorian changeover are applied as if today's rules had always held.
Why does the big green number keep changing?
That panel is a live clock rather than a converted result — it re-reads your device's time once a second and shows the current epoch value. It is there so you can grab a timestamp for a test fixture or compare it against an exp claim without any arithmetic. It has no effect on the fields below, which only change when you edit them.