Unix timestamp converter

What this timestamp converter does

The tool converts in both directions between Unix time and human-readable dates. Enter a timestamp and it returns the same instant as ISO 8601, an RFC-style UTC string and your browser’s local time, each with a copy button. Enter a date string and it returns the Unix timestamp in seconds. Seconds versus milliseconds are detected automatically from the digit count, so you can paste values straight from logs, database rows or Date.now() without thinking about which one you have.

How to use it

1. Type or paste a number into Unix timestamp (s or ms) and click Convert. The date field and the four outputs update.
2. Or type a date into Date string and click Convert. The timestamp field and the outputs update.
3. Copy the representation you need: Unix (s), ISO 8601, UTC or Local.
4. If the input cannot be parsed, an error appears under the fields and the previous result stays on screen.

Seconds vs milliseconds

Most systems disagree on the unit, and a mix-up produces dates in 1970 or in the year 56,000.

Source	Unit	Example (same instant)
POSIX time(), date +%s, Python time.time()	seconds	1700000000
JavaScript Date.now(), Java System.currentTimeMillis()	milliseconds	1700000000000
JWT iat / exp claims	seconds	1700000000
Stripe, GitHub, most REST APIs	seconds	1700000000
Firebase, MongoDB Date, Kafka	milliseconds	1700000000000
.NET ticks, Windows FILETIME	100-nanosecond units	not Unix time; divide before converting

Rule of thumb: a current timestamp has 10 digits in seconds and 13 in milliseconds. The tool uses that boundary. A 16-digit value is microseconds (Postgres epoch with fractions, some tracing systems); drop the last three digits before pasting.

Common formats for the same moment

Taking 1700000000 as the input:

Format	Value
Unix seconds	1700000000
Unix milliseconds	1700000000000
ISO 8601 (UTC)	2023-11-14T22:13:20.000Z
ISO 8601 with offset	2023-11-15T00:13:20+02:00
RFC 2822 / HTTP date	Tue, 14 Nov 2023 22:13:20 GMT
SQL DATETIME	2023-11-14 22:13:20

ISO 8601 is the one to standardize on in APIs and JSON. It sorts correctly as a string, carries its timezone, and JSON.stringify(new Date()) already emits it. The trailing Z means UTC; an offset like +02:00 means local time two hours ahead of UTC.

Timezones, DST and other traps

• Store UTC, display local. Keep timestamps or UTC ISO strings in the database and convert for display only. The Local output here uses your browser’s timezone, including daylight-saving rules, so it is a quick way to check what a user in your zone will see.
• Date-only strings are UTC. new Date('2024-03-15') is midnight UTC, while new Date('2024-03-15T00:00') (no Z) is midnight local. This asymmetry in the ECMAScript spec causes most off-by-one-day bugs.
• Leap seconds do not exist in Unix time. Each day is exactly 86,400 seconds; the clock is smeared or stepped by the OS instead.
• Month is zero-based in new Date(y, m, d) and getMonth(). January is 0.
• Expiry checks in JWTs compare exp (seconds) with Date.now() (milliseconds). Divide by 1000 or you will treat every token as valid for the next 50,000 years.

The year 2038 problem

Systems that store Unix time as a signed 32-bit integer overflow at 2147483647, which is 03:14:07 UTC on 19 January 2038. The next second wraps to -2147483648, or 13 December 1901. Modern operating systems, JavaScript (which uses 64-bit floats and milliseconds) and most databases are unaffected, but embedded firmware, old file formats and some MySQL TIMESTAMP columns (range ends in 2038) still are. If you maintain anything that will run for another decade, use 64-bit integers or DATETIME.

Related tools and snippets

• JWT decoder to read iat and exp claims, then paste them here to see when a token expires.
• Cron expression explainer when the question is not “what time is this” but “when does this run”.
• Number base converter for timestamps that arrived as hexadecimal, common in binary protocols.
• JSON formatter to pretty-print the API response you pulled the timestamp from.