A log line that just says 1755043200 tells you nothing about when it happened. A Unix timestamp counts the time elapsed since midnight UTC on 1 January 1970 as a single number — convenient for machines, unreadable for people. This tool turns that number into a date and converts back the other way.
Detecting the unit from digit count is what makes it practical day to day. The same instant is 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. JavaScript uses milliseconds, Python and Unix tooling use seconds, and databases and observability stacks often use micro- or nanoseconds — so they get mixed up constantly. Paste anything and it works out which you meant.
How to use
- Paste a timestamp or a date — Enter a number to get a date, or a date string like
2026-08-13T00:00:00Zto get a timestamp. Slash forms such as2026/08/13 09:00are recognised too. Leave the field empty and it tracks the current time, updating every second. - Check the unit — Auto-detect infers the unit from the number of digits. If it guessed wrong, pick seconds, milliseconds, microseconds or nanoseconds explicitly. Setting it manually is safer for very small values close to the 1970 epoch, where the heuristic has less to go on.
- Copy the format you need — The results table shows Unix seconds and milliseconds, ISO 8601, your local time, UTC and RFC 2822 side by side, each with its own copy button. ISO 8601 is what you want for API requests; RFC 2822 is what email headers use.
- View it in another timezone — Pick a timezone at the bottom to see the same instant as a local wall clock there. Useful for lining up an incident timeline with an overseas team, or reading a user's logs in the time they actually experienced.
Frequently asked questions
Why are some timestamps 10 digits and others 13?
It is the same instant counted in seconds versus milliseconds. Any time after September 2001 is 10 digits in seconds and 13 in milliseconds.
That gap causes the classic "everything shows 1970" bug: read a millisecond value as seconds and you land near the epoch; read a seconds value as milliseconds and you land 50,000 years out. If a date renders with an absurd year, check whether you need to multiply or divide by 1000 before looking anywhere else.
What is the year 2038 problem?
Systems that store timestamps in a signed 32-bit integer overflow just after 03:14:07 UTC on 19 January 2038, wrapping to a negative number and rendering as 1901.
Modern systems use 64-bit values, so this is rarely a live concern. It still lurks in old embedded devices, legacy C code, and MySQL's TIMESTAMP column, whose range stops at 2038-01-19. If you store dates far in the future — expiry dates, long contracts — use DATETIME or a 64-bit integer.
Are leap seconds accounted for?
No. Unix time is defined as though every day has exactly 86,400 seconds and simply does not count leap seconds. When one is inserted, systems either repeat a timestamp or smear the clock gradually across the day.
For almost every application this is irrelevant. If sub-second ordering genuinely matters — trade sequencing, distributed event ordering — use a logical clock or a monotonic counter rather than wall-clock timestamps.
The local time shown does not match my computer.
The "local time" row uses whatever timezone the browser reports. If your OS timezone is set to something other than where you are, or you opened this inside a VM, container or over a VPN, it follows that setting.
The "your timezone" card at the top shows the timezone the browser detected — check that first. If it says UTC, you are almost certainly in an environment where no timezone was configured.
Concepts worth knowing
Why the epoch is 1970
1 January 1970 is an arbitrary marker chosen because it was close to when Unix was being written. Early Unix counted in sixtieths of a second, which a 32-bit counter exhausts in about two and a half years, so the unit became seconds and the origin was rounded to the start of 1970.
Other systems chose differently. Windows file times count 100-nanosecond intervals from 1601; Excel counts days from an imaginary 0 January 1900. That is why feeding an exported Excel date column straight into a timestamp parser produces nonsense.
A timestamp has no timezone
This trips people up constantly. A Unix timestamp is an absolute instant measured against UTC and carries no location. 1755043200 generated in Seoul and 1755043200 generated in New York refer to precisely the same moment.
Timezones only enter when you render that number for a human. So the rule is: store timestamps or UTC in your database, and convert to the viewer's timezone only at display time. Storing local wall-clock time instead creates hours that occur twice or never at all across daylight-saving transitions.
Why ISO 8601 should be your default
2026-08-13T00:00:00Z is an international standard with a valuable property: sorting it as plain text gives you chronological order. Running sort over a log file is enough to order it by time.
Compare that with 08/13/2026, where the American month-first and European day-first conventions collide and nobody can tell March 4th from April 3rd. Standardise on ISO 8601 for any date crossing an API boundary, and always include the trailing Z or an offset like +09:00 — a date string without one gets interpreted however the receiver feels like.