Unix Timestamp Converter

What a Unix timestamp counts

A Unix timestamp is the number of seconds (sometimes milliseconds) since 00:00:00 UTC on 1 January 1970, the epoch. Negative numbers are times before that instant. This page reads either a raw number or a date string, then writes every common representation: seconds, milliseconds, ISO 8601 in UTC, the older UTC string, your local Date string, and a relative phrase such as 3 days ago.

Databases, logs, and most Unix tools store seconds. JavaScript Date.now() and many APIs store milliseconds. Mixing them up shifts a date by a factor of 1000, which looks like the year 1970 or the year 50,000. The page picks a unit from the digit count so you rarely have to choose.

Worked example: an expiry date that shows January 1970

An API returns "expires_at": 1791475200, and the web app shows the subscription as expired on 21 January 1970. Paste 1791475200 and press Convert.

Input type reads Unix (s), because the value has 10 digits. The ISO 8601 (UTC) line shows 2026-10-08T16:00:00.000Z, a sensible expiry. So the API is fine, and the bug is in the front end.

JavaScript's new Date(number) expects milliseconds. new Date(1791475200) is 1,791,475,200 milliseconds after the epoch, which is 1970-01-21T17:37:55.200Z. The fix is new Date(expires_at * 1000). To confirm the fix without running the app, paste 1791475200000 into the converter: Input type switches to Unix (ms), and the date is the same 2026-10-08T16:00:00.000Z.

Any date in January 1970 on a screen is worth this two-step check. It almost always means a value in seconds was handed to code that expected milliseconds.

How to use Convert and Now

1. Paste a number or a date into the left pane. The placeholder shows the three shapes the parser likes: a raw integer, an ISO string with a Z, or a loose date such as Jan 15 2024.
2. Click Convert, or press Enter. The right pane fills with six labeled lines. Status becomes Converted. The strip shows Unix (s), Your zone as an offset such as UTC-03:00, and Input type: Unix (s), Unix (ms), or Date string.
3. Now writes the current time as Unix seconds (not milliseconds) into the input and converts immediately. That is the same integer you would get from date +%s on a Unix machine.
4. Copy result copies all six output lines. Clear empties both panes.

A string of digits is treated as milliseconds when it has 13 or more digits (ignoring a leading minus). Shorter integers are treated as seconds, then multiplied by 1000 internally. A value the Date constructor cannot represent sets Status to Timestamp is out of range. A string the browser cannot parse sets Status to Unrecognized date or timestamp.

Reference conversions

Seconds. Input 1700000000, click Convert. Input type: Unix (s). Output includes:

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

The Local line uses your device timezone and language. Relative is computed from the clock at the moment you convert, so it will say something like 2 years ago rather than a fixed phrase.

The same instant as milliseconds. Input 1700000000000. Input type becomes Unix (ms). The six lines are the same instant as above. If you had treated that number as seconds you would land in the year 55851, which is how you notice a unit mismatch in a log.

An ISO string. Input 2024-01-15T09:30:00Z. Input type: Date string. Unix seconds: 1705311000. Unix milliseconds: 1705311000000. ISO line: 2024-01-15T09:30:00.000Z. UTC line: Mon, 15 Jan 2024 09:30:00 GMT. The trailing Z is what pins the parse to UTC. Without it, the browser treats a date-time as local time, so the Unix number will shift by your offset.

Epoch itself: input 0 yields 1970-01-01T00:00:00.000Z.

When to convert

Use it when a log or a database row gives you 1700000000 and you want a calendar date, or when a ticket says “15 January 2024, 09:30 UTC” and you need the integer to put in a query. It is also a quick check that two systems agree on epoch units.

• Reading a created_at column that is stored as an integer
• Comparing a server log timestamp with what your laptop clock says
• Getting both the seconds and milliseconds forms of the same instant

Unit and zone mistakes

• Pasting 13 digits and assuming seconds. This page will treat them as milliseconds, which is usually what you want, but a 13-digit seconds value (far-future) would be misread.
• Omitting the Z or an offset on an ISO string, then comparing the Unix number to a server that stored UTC. Add Z when you mean UTC.
• Reading the Local line as UTC. Local is Date.prototype.toString() in your zone. The ISO and UTC lines are the ones that do not depend on the laptop.
• Expecting nanoseconds or a 19-digit integer to work. Extra digits become a huge millisecond value or fail as out of range.

What this converter does not do

It does not convert between named timezones (no picker for America/Sao_Paulo versus Europe/Berlin). The only zone it knows is the one your browser is using, plus UTC. It does not handle cron-style next-run math (use the cron page). It does not format a custom string such as YYYY/MM/DD. It does not account for leap seconds; like most Unix clocks, it pretends they do not exist.

Privacy

Parsing uses your device clock and timezone. The number or string you type is not sent to a server. Closing the tab clears it.