What is a Unix timestamp?

The number of seconds elapsed since midnight UTC on January 1, 1970 — the 'Unix epoch.' It's the canonical way databases, file systems, log files, and most APIs store a point in time. A Unix timestamp is just an integer, so there's no timezone confusion, no string parsing, and no locale-specific formatting surprises. Many modern systems use milliseconds instead of seconds (that's what JavaScript's Date.now() returns), but both refer to the same epoch.

Why would I pick seconds vs milliseconds?

Seconds is the traditional Unix form and what most databases, config files, and APIs expect. Milliseconds is what JavaScript uses natively (Date.now() and new Date(ms)), and what JSON APIs from JavaScript backends often emit. If you're moving a timestamp between a browser frontend and a SQL column, you're usually converting from ms to seconds by dividing by 1000. The tool handles both and shows both side by side so you can grab whichever one your target system wants.

What's the Y2038 problem?

At 03:14:07 UTC on January 19, 2038, a signed 32-bit seconds counter will overflow. Systems that store Unix timestamps as signed 32-bit integers (historically: old Unix file systems, 32-bit C code, many embedded systems) will wrap around to a negative number and misread the time. Modern systems use 64-bit integers, which push the overflow so far into the future it doesn't matter. This tool uses JavaScript numbers (IEEE 754 doubles) under the hood, so Y2038 isn't a problem for the display, but if you're integrating with something 32-bit-aware, test the boundary explicitly.

Why does the local time differ from UTC?

Because you're not in the UTC timezone. UTC is the reference clock — API servers, databases, and Unix timestamps themselves all count from UTC midnight. Your local clock is UTC plus or minus your timezone offset, and that offset might shift for daylight saving. The tool reads your local offset from the browser's operating system and shows both the UTC and local views so you can see what a timestamp means in whichever frame you care about.

Can I paste a timestamp from a log file?

Yes — paste the number into the timestamp field and pick the right unit. If the log emits something like '1776263696.123' with a decimal, leave it in seconds mode; the tool honours fractional seconds down to millisecond precision. If it's a big integer like '1776263696789', pick milliseconds. If you don't know which it is, a quick heuristic: timestamps in seconds have 10 digits for current-era dates, timestamps in milliseconds have 13. Ten-digit numbers starting with 16, 17, or 18 are seconds; thirteen-digit numbers starting with 16, 17, or 18 are milliseconds.

Unix Timestamp Converter — Online Time Converter

Estimates for educational purposes — not financial, medical, or legal advice. See terms.

Convert a Unix epoch timestamp (seconds or milliseconds) into every common human-readable format, or go the other direction: paste a date string and see what the timestamp should be. Useful for debugging API payloads, reading log files, setting cache TTLs, writing database fixtures, and answering “when did this actually happen?” questions without opening a REPL.

What this tool does

Two linked inputs:

Unix timestamp — a number (seconds or milliseconds since the 1970 epoch) with a unit toggle
ISO 8601 date — a string like 2026-04-15T12:34:56Z

Edit either side and the other updates to match. The results card below shows the same instant in seven forms (Unix seconds, Unix milliseconds, ISO 8601 UTC, ISO 8601 local, human-readable UTC, human-readable local, and RFC 2822) with a copy button on each row. A “Use current time” button grabs Date.now() and populates both fields with the current instant.

The tool uses JavaScript’s native Date object under the hood, which covers the full range from about 271,821 BCE to 275,760 CE. Any timestamp in that range — including negative values for pre-epoch dates — converts without drama.

Example: debugging an API response

You’re integration-testing a webhook and the server sends you {"created_at": 1776263696}. Paste 1776263696 into the timestamp field, leave the unit on seconds. The tool shows:

ISO 8601 UTC: 2026-04-15T12:34:56.000Z
Human (UTC): Wednesday, 15 April 2026 at 12:34:56 UTC
Human (local): the same instant translated to your browser’s timezone

That’s the answer to “when was this webhook event created?” in about two seconds.

Example: generating a test fixture

You’re writing a snapshot test and need a fixed timestamp that represents 2026-04-15 at noon UTC. Paste 2026-04-15T12:00:00Z into the ISO field. The tool shows:

Unix (seconds): 1776254400
Unix (ms): 1776254400000

Copy whichever one your fixture uses. No REPL, no new Date(...).getTime() / 1000 math, no off-by-an-hour bug because you forgot to specify the timezone.

Example: the Y2038 boundary

Paste 2147483647 in seconds mode. You get 2038-01-19T03:14:07.000Z — the exact last moment that a signed 32-bit seconds counter can represent. Add one second (paste 2147483648) and you see 2038-01-19T03:14:08.000Z — one second later, which is where legacy 32-bit systems wrap around to a negative number.

The tool itself uses 64-bit floating-point under the hood, so the display is fine on both sides of the boundary. If you’re testing code that might be 32-bit-aware (old C libraries, embedded firmware, some SQL column types), this is how to generate the test inputs.

Seconds vs milliseconds

Use seconds when integrating with:

Traditional Unix timestamps (POSIX time(), Unix file mtimes)
Most SQL TIMESTAMP / BIGINT columns that store epoch time
Config files and environment variables
Go’s time.Unix(), Python’s time.time(), Ruby’s Time#to_i
Slack, Stripe, and many other webhook timestamps

Use milliseconds when integrating with:

JavaScript Date.now() / new Date(ms)
Firebase, MongoDB ISODate, and many JSON APIs from Node backends
Java System.currentTimeMillis()
Browser performance APIs (though those are usually relative, not epoch)

The tool shows both in the result card, so you can copy whichever one your target system expects without doing the divide-by-1000 by hand.

UTC vs local time

API responses and database columns almost always store UTC. Human-readable outputs almost always want local time. The tool shows both because you usually need them both at once: “the server logged this at 16:34 UTC — what does that look like on my laptop clock?” is a daily question, and the side-by-side view answers it directly.

Your local offset comes from the browser’s operating system, so it’s automatically correct for daylight saving — whatever offset is active at the moment you load the page is what you get.

What this tool does not do

It doesn’t parse non-ISO date strings — slashes, month names, relative phrases like “yesterday.” If you need that, use a date-parsing library or the browser’s Date.parse() directly (which is stricter than most people think).

It doesn’t account for leap seconds. Unix timestamps traditionally don’t, and neither do most practical systems — leap seconds are either smeared across the day or ignored entirely.

It doesn’t support named timezones like America/New_York in output. The tool only displays the browser’s local zone (whatever that is) alongside UTC. For zone-aware display across multiple named zones, the timezone converter is the right tool; for formatted ISO 8601 strings specifically, the ISO 8601 parser handles input and output.

It doesn’t handle timestamps outside the JavaScript Date range — roughly ±100 million days from the epoch, which is far enough into the past or future that it probably doesn’t matter, but worth knowing if you’re working with geologic time.

Unix Timestamp Converter