Timestamp Converter

What the Unix epoch is

A Unix timestamp counts time in seconds since the Unix epoch: midnight Coordinated Universal Time (UTC) on January 1, 1970. That instant is written 1970-01-01T00:00:00Z in ISO 8601. The count is simply the number of seconds that have elapsed since then — no timezone math, no calendar. This converter counts forward (positive values) and backward (negative values, for dates before 1970) from that moment, which is why the whole epoch system is one number that every system can agree on.

Seconds vs milliseconds

Many APIs write Unix time in whole seconds, but JavaScript and many databases write it in milliseconds. The same date looks very different: 2026-09-18T12:30:00Z is 1789734600 seconds and 1789734600000 milliseconds. A timestamp ending in three extra zeros is usually the milliseconds form, but not always — a real seconds value can legitimately end in zeros too.

This converter combines magnitude with validity. A value below 10^11 is treated as seconds; a value at 10^11 or above is treated as milliseconds, because that is where millisecond timestamps for real dates (roughly from 1973 onward) live. Any value that would land outside the range JavaScript dates can represent — about 275,000 years on either side of 1970 — is rejected with a clear message instead of guessed at.

• 2026-09-18T12:30:00Z → seconds 1789734600, milliseconds 1789734600000.
• Same instant, same UTC moment — only the unit changes.
• Values at or above 10^11 are read as milliseconds.

ISO 8601 date/times

ISO 8601 is the standard way to write a date and time as text: 2026-09-18T12:30:00Z means September 18, 2026 at 12:30:00 UTC. The trailing Z declares UTC. An explicit offset instead — 2026-09-18T18:00:00+05:30 — declares a local wall clock and how far east (or west) it sits from UTC, and this converter resolves it to the same UTC instant either way.

When no timezone is supplied at all, the value is interpreted in your browser's local timezone, exactly as if you typed it as a local wall clock. The tool says so explicitly rather than silently assuming UTC, because a timezone-less date is genuinely ambiguous between machines.

UTC vs local time

UTC is a single, timezone-free reference: every instant has exactly one UTC time. Your local time is that same instant displayed in your browser's timezone, which differs by the current UTC offset and, in many places, changes over the year with daylight saving time.

The result cards always show both. The UTC card is the same for every visitor; the Local card reflects the browser running the tool, so a timestamp converter in one office can show a different local string than in another — for the same instant. When interpreting timezone-less input, the browser's own rules are used, and the tool labels that interpretation clearly.

Timestamps in APIs and logs

APIs, databases and file formats use Unix timestamps because they are compact, unambiguous and timezone-free. REST responses embed expirations and issued-at values as epoch numbers; log lines prefix events with epoch seconds or ISO strings; database columns commonly store bigint milliseconds. Round-tripping between these forms — a log line's ISO string to the numeric value a query expects — is exactly the workflow this tool is built for.

When you paste a value from an API response or a log line, the detection summary tells you which unit was assumed, so you can spot a mismatch (a value read as seconds when the source meant milliseconds) before it becomes a bug.

JWT NumericDate claims

JSON Web Tokens encode their time claims — exp (expiration), iat (issued at) and nbf (not before) — as NumericDates: Unix timestamps in whole seconds. That is the same second-based epoch this tool converts. Paste one of those values here to see the exact expiry, issue or not-before moment in UTC, local time and relative terms.

The JWT Decoder already converts those claims for you when you decode a whole token; this tool is the standalone companion when all you have is the raw number — for example, from server logs or a decoded payload you want to double-check.

How to convert a timestamp to a date

Paste the numeric timestamp into the input box. If the value is below 10^11 it is read as seconds, and at or above that magnitude as milliseconds; the summary line states which unit was assumed. Every representation of that one instant appears at once: Unix seconds, Unix milliseconds, the ISO 8601 UTC string, a human-readable UTC date, the same instant in your browser's local timezone, and a relative phrase such as "3 days ago" or "in 3 days".

How to convert a date to a timestamp

Paste an ISO 8601 date and time instead of a number and read the Unix seconds or Unix milliseconds card. End the value with Z to state UTC explicitly — 2026-09-18T12:30:00Z. An explicit offset such as +05:30 is resolved to the same UTC instant, so you can confirm what a server-side timestamp will resolve to. Leaving the timezone off interprets the value in your browser's local time, and the tool labels that clearly instead of guessing.

Seconds and milliseconds cards are both always shown, so copying a value in the unit your API, log, or database column expects takes one click. Note that this is a conversion tool, not a scheduler — to build or explain a recurring schedule, use the Cron Expression Generator.

Is timestamp data uploaded?

No. Timestamp values are processed locally in your browser and are not uploaded to TechFixGen. Conversion runs entirely client-side with no formatting or conversion request. Reloading the page clears the input; the value is not stored in the URL, localStorage, or sessionStorage. Copy writes a value to your clipboard only when you click that card's copy button.

Common mistakes to avoid

The classic traps are unit confusion and timezone confusion. A seconds value pasted where milliseconds are expected is off by a factor of 1000 — a year 2286 date instead of 2026. A local time pasted as if it were UTC shifts every displayed value by your offset. And ambiguous forms like 09/10/2026 or date-only values carry hidden assumptions about month order and timezone, which is why this tool asks for unambiguous ISO input instead of guessing.

The tool keeps every interpretation visible: which unit was detected, whether the input supplied a timezone, and when a fractional part had to be rounded to millisecond precision.