Unix Timestamp Converter: Seconds and Dates
Convert a Unix timestamp to a date or a date to a timestamp. Check the expected time unit and timezone when comparing logs or API values.
Unix Timestamp Converter workspace
Timestamp to Date
Supports Unix timestamps in seconds, milliseconds, and microseconds.
Date to Timestamp
Enter a timestamp or date to see results
TimeZone Support
Instantly view converted dates in both UTC and your local timezone.
Relative Time
See human-friendly relative time formats like '2 hours ago' or 'in 5 days'.
Date to Timestamp
Easily convert any calendar date back into a Unix timestamp.
Real-time Epoch
Always see the current live Unix timestamp at the top of the tool.
Unix Timestamp Converter: Epoch to Date, and Date to Epoch
Convert a Unix timestamp to a date or a date to a timestamp. Check the expected time unit and timezone when comparing logs or API values. Unix timestamps describe an instant relative to the Unix epoch. A seconds value and a milliseconds value represent very different dates if interpreted with the wrong unit. Compare the timezone used for display with the timezone used by the system you are debugging.
How to use the Unix timestamp converter
- Read the live Current Unix Epoch Time ticker at the top — press Pause to freeze it for copying.
- In the Timestamp to Date card, type or paste an epoch value (seconds, milliseconds, or microseconds), then press Convert.
- Read the four outputs: Unix Timestamp, UTC Date, Local Date, and a Relative phrase such as "2 hours ago".
- To go the other way, use the Date to Timestamp card, pick a date and time, and press Convert — the input is read in your local timezone.
- Click the copy icon next to any field to send that value to your clipboard. Leave the input empty and press Convert to use the current epoch.
What is Unix epoch time, and how does it work?
Unix time is the number of non-leap seconds that have passed since the Unix epoch, 00:00:00 UTC on January 1, 1970. The value is a single integer, which makes it trivial to store, sort, and subtract. Because it is anchored to UTC, one timestamp names the same instant everywhere on Earth — timezone is only applied when you display it.
A detail most converters skip: by the POSIX definition, "each and every day shall be accounted for by exactly 86,400 seconds." That means Unix time deliberately ignores leap seconds, so it trades astronomical exactness for clean arithmetic. This tool converts using the JavaScript Date object: new Date(seconds * 1000) for epoch→date and Math.floor(date.getTime() / 1000) for date→epoch, then formats with toISOString() (ISO 8601), toUTCString() (UTC), and toLocaleString() (local). For the date and time format spec itself, see the ISO 8601 standard.
Worked examples: input → output
Epoch seconds → date
1700000000 → UTC: Tue, 14 Nov 2023 22:13:20 GMT · ISO: 2023-11-14T22:13:20.000Z
Milliseconds → date
1700000000000 → same instant; the 13-character input is read as milliseconds, not seconds.
The epoch zero point
0 → UTC: Thu, 01 Jan 1970 00:00:00 GMT
Edge case · Year 2038 overflow
Convert 2147483647 and you get 2038-01-19 03:14:07 UTC — the largest value a signed 32-bit timestamp can hold. The very next second overflows on 32-bit systems and is misread as 1901-12-13 20:45:52 UTC. This tool uses 64-bit JavaScript numbers, so it keeps converting correctly far past 2038.
Epoch reference values
Common epoch milestones and the exact second-counts behind everyday durations. The duration values are precise because Unix time treats every day as exactly 86,400 seconds.
| Unix value | UTC date / meaning | Notes |
|---|---|---|
| 0 | 1970-01-01 00:00:00 | The Unix epoch (start) |
| 3,600 | 1 hour | Common session / token TTL |
| 86,400 | 1 day | Always exactly 86,400 s (POSIX) |
| 604,800 | 1 week | 7 × 86,400 |
| 1,000,000,000 | 2001-09-09 01:46:40 | The "Giga-epoch" milestone |
| 2,147,483,647 | 2038-01-19 03:14:07 | Max signed 32-bit timestamp (Y2K38) |
The seconds-vs-milliseconds rule this tool actually uses
Most explanations say "10 digits is seconds, 13 digits is milliseconds." Under the hood this converter is stricter and simpler: it switches to milliseconds when the input string is longer than 11 characters (timestamp.toString().length > 11), otherwise it treats the value as seconds and multiplies by 1000. So an 11-digit second value still reads as seconds, while a 12-digit value already flips to milliseconds.
The practical gotcha: that length test counts every character, including a leading minus sign. A negative pre-1970 timestamp like -1000000000 is 11 characters, so it stays in seconds — but pad it and the count can tip it into milliseconds. When in doubt, normalize to a clean integer first, or paste the millisecond value and let the tool detect it.
Related time, date & calculation tools
Translate wall-clock time across regions
Date Difference CalculatorCount days, weeks & months between dates
Age CalculatorFind exact age in years, months & days
Cron Expression BuilderSchedule jobs with a next-fire preview
Unit ConverterConvert time, length, weight & more
Number Base ConverterRead epoch values in hex, octal & binary
Percentage CalculatorQuick percentage and change math
Pomodoro TimerTime focused work in 25-minute blocks
Compound Interest CalculatorProject growth over time periods
Tip CalculatorSplit a bill and tip in seconds
Aspect Ratio CalculatorSolve width and height proportions
All ToolsBrowse the full Toolk hub
Guide: Unix Timestamps & EpochHow epoch time, leap seconds & Y2K38 work
Last updated: September 15, 2026 · Runs 100% in your browser — no uploads, tool input is not sent to Toolk.
Frequently asked questions
How does the tool decide whether my number is seconds or milliseconds?
It uses a length test, not digit-count folklore: input strings longer than 11 characters are treated as milliseconds, anything shorter is multiplied by 1000 as seconds. The subtle catch is that every character counts, including a leading minus sign on pre-1970 values — normalize to a clean integer if a negative timestamp ever looks misread.
Will timestamps stop working correctly after the Year 2038 problem?
Not here. The overflow at 2038-01-19 03:14:07 UTC only bites signed 32-bit counters; this converter works with 64-bit JavaScript numbers, so it converts correctly far beyond the boundary. Legacy 32-bit systems will misread those same values as dates in 1901, which is worth knowing when you read their logs.
Are the timestamps I paste or the dates I pick sent anywhere?
No. Conversions run locally with the JavaScript Date object and the live epoch ticker reads your own system clock once per second — tool input is not sent to Toolk, and Toolk's page analytics never receive the values you enter.
How do I show one instant in several regions' wall-clock time?
Convert to the absolute epoch value first, then hand it to Toolk's timezone converter (/tools/timezone-converter) to render that single instant across named zones with daylight-saving rules applied — the pair covers logging on one side and human scheduling on the other.