Unix Timestamp Converter

A Unix timestamp is the cleanest way a computer can store an instant: one integer, no time zone, no formatting, no ambiguity about whether 03/02 is March or February. That is exactly why it is unreadable to a person. Converting it back is the moment a log line, a database column or an API response stops being a number and starts being an event you can reason about.

Convert Unix timestamps to human-readable dates and convert dates back to epoch time with second-level precision.

This converter reads an epoch value in any of the four Unix units, in Excel serial form, in .NET ticks, in Windows FILETIME and in Chrome's internal microseconds, and it writes a date back out in the same range of forms. Every conversion happens on your device as you type, and every value on screen can be copied with one press.

Benefits of Timestamp Conversion

• Date readability: a ten-digit integer becomes a date, a weekday, an ISO week and a day of the year.
• Database work: read a stored column back without writing a query just to format it.
• API development: check what a payload actually means before you trust the client that renders it.
• Debugging: compare two timestamps from two systems in the same units, in the same zone.
• Format conversion: move between epoch, ISO 8601, RFC 3339, RFC 2822 and SQL without a script.

Unix time counts seconds elapsed since 1 January 1970 at 00:00 UTC, an origin called the Unix epoch. It does not count leap seconds: every day is exactly 86,400 seconds long by definition, which is what makes the arithmetic simple and what makes the number an approximation of true elapsed time rather than a measurement of it.

Timestamp Characteristics

• Counts from 1 January 1970 at 00:00 UTC, and can go negative for earlier instants.
• Carries no time zone, so the same value means the same instant everywhere on earth.
• Sorts and compares as a plain integer, which is why databases store it.
• Ignores leap seconds — a Unix day is always exactly 86,400 seconds.
• Comes in four common units: seconds, milliseconds, microseconds and nanoseconds.

Date Format Characteristics

• Readable by a person without a lookup, which an integer never is.
• Carries a zone or an offset, so it names a wall clock as well as an instant.
• Comes in competing standards — ISO 8601, RFC 3339, RFC 2822 and SQL all differ in detail.
• Is ambiguous when written as numbers alone: 03/02/2026 is two different days.
• Needs a calendar to compare, where timestamps need only subtraction.

The same instant is written four different ways depending on the unit a system chose, and the four differ only by trailing zeros — which is why pasting the wrong one produces a date in 1970 or in the year 56000 rather than an error.

How the Unit Is Detected

By the number of digits in the integer part, not by the magnitude of the value: up to 11 digits is read as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds and 18 or more as nanoseconds. Those ranges are chosen so every instant from 1973 to the year 5138 resolves the same way in every unit. Below 1973 the ambiguity is real — 1000000 is 12 January 1970 in seconds and 1 January 1970 in milliseconds — so the panel names the unit it chose and the rail lets you state it outright.

Why Nanoseconds Need Exact Arithmetic

A nanosecond epoch value for any date after September 2001 is larger than 9,007,199,254,740,991, the largest integer an ordinary floating-point number can hold exactly. A converter that reads nanoseconds into a number and prints them back therefore loses up to 256 nanoseconds, silently, and the output still looks like a plausible timestamp. This converter carries the value as an exact integer from the moment it is read to the moment it is printed, so the nanosecond output is the digits you pasted.

Unix time is not the only origin in use. Four others turn up often enough that a timestamp converter that cannot read them sends you looking for a second tool, so all four are supported here and named in the panel when one is detected.

Excel Serial Dates

Excel counts days from 1899-12-31, with the day fraction after the decimal point — and it treats 1900 as a leap year, which it was not. Serial 60 is therefore 29 February 1900, a date that never happened, kept for compatibility with Lotus 1-2-3. Every serial from 61 onward is one day ahead of a naive count and every serial below 60 is not, so the usual fix of subtracting one everywhere is wrong for 125 years of dates. This converter handles the split correctly and reports serial 60 rather than inventing a date for it.

Ticks, FILETIME and Chrome Time

.NET ticks are 100-nanosecond intervals from 0001-01-01. Windows FILETIME uses the same 100-nanosecond tick but counts from 1601-01-01. Chrome and WebKit store microseconds from that same 1601 origin. All three are large integers that look like nothing in particular, which is why they are worth naming: choose the format in the rail and the conversion is exact, with the nanosecond precision preserved end to end.

A timestamp has no time zone. A date does. Every bug in a timestamp converter lives in the gap between those two sentences, and it is the reason this tool puts a named zone next to the input rather than quietly using the one your browser happens to be in.

Why a Local Date Needs a Named Zone

If you type 3 February 2026 at 14:05 with no offset, that is a wall clock, not an instant — it is a different moment in Kolkata than it is in London. A converter that reads it in the browser's own zone gives a different answer to two people looking at the same screen share, and neither of them is told which zone was used. Here the zone is an explicit control, the result states which zone it used and what the offset was at that instant, and the strip below shows the same moment in every place you have added.

Gaps and Overlaps

Twice a year a zone with daylight saving skips an hour and repeats another. A wall time inside the skipped hour never happens, and a wall time inside the repeated hour happens twice. Most converters pick one silently. This one tells you which case you are in and lets you choose whether an ambiguous time means the earlier instant, the later one, or should be refused outright.

The most famous boundary in Unix time is not the epoch, it is the ceiling. It is close enough now that embedded devices, file formats and long-lived databases are being tested against it in earnest.

What Overflows

A signed 32-bit time_t holds values up to 2,147,483,647, which is 03:14:07 UTC on 19 January 2038. One second later the value wraps to negative and the same system reads it as 13 December 1901. Anything that stores a timestamp in four signed bytes is affected — old C code, some binary file headers, a few network protocols and a great deal of embedded firmware.

What to Do About It

Store 64-bit values, and test the boundary rather than assuming it. The rail here offers 2038 and the unsigned 32-bit ceiling in 2106 as one-press jumps, so you can paste the exact value a system should choke on and compare what it reports against what the date really is. This converter has no 32-bit limit of its own: it reads the whole representable range, roughly 275,760 years either side of 1970, and refuses anything past it with a message rather than a wrong answer.

Three modes cover the three questions people arrive with, and a fourth handles a whole list at once. Nothing needs to be uploaded and nothing needs an account.

1. 1. Convert timestamp to date

   Choose Timestamp to date and paste the number, for example 1704067200. The unit is detected from the digit count, and the result appears in every format at once.

2. 2. Convert date to timestamp

   Choose Date to timestamp and type the date, for example 2026-02-03T14:05:06Z. Pick the time zone the date should be read in, and the epoch value appears in all four units.

3. 3. Use current time

   Live epoch shows the current timestamp ticking. Pause it to copy an exact value, or send that moment straight into the converter.

Convert when the number has to be read by a person, compared against a clock, or lined up with an event recorded in a different system.

Ideal Use Cases

• Reading a log column: paste the whole column into Bulk list and get a table you can scan.
• Database work: turn a stored integer into a date in the zone your users are actually in.
• API responses: check whether a field is seconds or milliseconds before writing the client.
• Testing boundaries: feed a system the 2038 or 2106 value and see what it reports.
• Cross-system comparison: put a .NET tick count and a Unix millisecond value in the same units.

A handful of numbers that explain most of the surprises people hit with epoch time.

Key Statistics

• Unix seconds needed a tenth digit on 9 September 2001, at exactly 1000000000.
• The signed 32-bit ceiling is 2147483647 seconds: 19 January 2038 at 03:14:07 UTC.
• The unsigned 32-bit ceiling is 4294967295 seconds: 7 February 2106 at 06:28:15 UTC.
• Nanosecond epoch values passed the exact-integer limit of a floating-point number in 2001.
• A Unix day is always 86,400 seconds — leap seconds are not counted.
• Excel serial 60 is 29 February 1900, a date that never existed.

A few habits that stop a timestamp from being wrong in a way nobody notices.

Quality Considerations

• Count the digits before assuming a value is seconds — ten and thirteen look alike at a glance.
• State the zone when you write a date down; an offset in the string beats a convention in your head.
• Store and transport timestamps as integers, and format them only at the edge.
• Use 64-bit storage for anything that will outlive 2038.
• When a value crosses a daylight-saving boundary, check which instant an ambiguous wall time meant.

When Not to Use

• Do not use a timestamp to record a birthday or a public holiday — those are calendar dates, not instants.
• Do not compare timestamps from systems whose clocks are not synchronised and expect millisecond accuracy.
• Do not use epoch seconds where you need leap-second accuracy; Unix time does not count them.
• Do not convert a wall-clock time without naming the zone it belongs to.

Everything runs on your device, so the ceiling is your hardware rather than a server quota. The Free caps exist where a person stops and a script starts.

• Bulk rows: Free converts 100 rows in one pass. Pro is limited only by what your device will hold.
• Places compared: Free shows one instant in 4 places at once. Pro adds as many as your device will draw.
• Paste size: up to 10 MB of text on Free, unbounded on Pro.
• CSV export and share links: Pro. Copying any value on screen is always free.
• Leap seconds: not representable in Unix time, and not in the clock a device keeps, so 23:59:60 is refused rather than rounded.

No timestamp, date or pasted list ever leaves the page. There is no upload step, no queue and no server to trust, which is why the converter keeps working with the network disconnected and why a list pulled out of a production log is safe to paste into it.

• Time & date converters
• All-in-one timezone converter
• Age calculator
• Date calculator
• UTC to Mumbai