dev101.io

Unix Timestamp Converter

Convert between Unix epoch and human-readable dates

Loading tool…

How to use Unix Timestamp Converter

  1. Paste a Unix timestamp (seconds, ms, µs, or ns), an ISO 8601 date, or any parseable date string into the input field.
  2. Read every representation in the grid below — 12 formats including Unix sec, Unix ms, ISO 8601, RFC 2822, local, UTC, relative, day of week, day of year, and ISO week.
  3. Click the Copy button on any card to grab just that format, or use the Share button to round-trip your input in a URL.
  4. Click Now (or press ⌘/Ctrl + Enter) to fill the input with the current Unix seconds.
  5. To convert a spreadsheet date, paste the "YYYY-MM-DD HH:MM:SS" string directly — it is interpreted in your local timezone so the numeric Unix value matches what your spreadsheet shows.

Unix Timestamp Converter

A bidirectional Unix timestamp converter that takes any date-like string — raw epoch seconds, milliseconds, an ISO 8601 string, an RFC 2822 wire date, a spreadsheet date — and prints every canonical representation you might need. The transform runs entirely in your browser with zero network calls, so debugging production timestamps, API payloads, and session cookies never leaks the values to a logging server.

Why a dedicated epoch converter

Most online Unix time tools fall into one of three failure modes. Some are stuck supporting only 10-digit seconds and silently misinterpret 13-digit millisecond timestamps as year-55000 dates. Some wrap the conversion behind a server round-trip and log every input. Some require clicking through three separate forms for "seconds to date", "date to seconds", and "ISO to date" when the underlying operation is a single parse-then-format.

This Unix timestamp converter takes a different stance. One smart input field accepts anything that resembles a timestamp or a date. The output grid shows all 12 representations at once — Unix seconds, Unix milliseconds, ISO 8601 in both local and UTC forms, RFC 2822 wire format, two localised human renderings, verbose UTC, relative-to-now phrasing, day-of-week, day-of-year, and ISO 8601 week number. Every card has its own copy button so you can grab just the one format your log viewer needs.

What the converter accepts

  • Unix seconds — any integer of 10 digits or fewer, including negative values for pre-1970 dates and fractional seconds for sub-second precision.
  • Unix milliseconds — 13-digit integers, the format emitted by Date.now(), most JSON APIs, modern telemetry pipelines, and Java/Kotlin System.currentTimeMillis().
  • Unix microseconds — 16-digit integers, common in high-resolution tracing systems and Postgres timestamp columns.
  • Unix nanoseconds — 19-digit integers, the native precision of Go's time.Now().UnixNano() and the OpenTelemetry wire format.
  • ISO 8601 / RFC 3339 — with or without timezone offset (Z, +05:30, -08:00), with or without fractional seconds.
  • RFC 2822 / RFC 5322 — the wire format HTTP headers and email envelopes use (Fri, 01 Mar 2024 12:34:56 GMT).
  • Spreadsheet-style stringsYYYY-MM-DD HH:MM:SS is treated as local time to match what Excel, Google Sheets, and most SQL clients display.
  • Bare datesYYYY-MM-DD is treated as UTC midnight, matching Date.parse semantics.

Units are auto-detected by digit count so you never have to pick a dropdown. A 10-digit integer is seconds; a 13-digit integer is milliseconds; a 16-digit integer is microseconds; a 19-digit integer is nanoseconds. Negative inputs are pre-1970 timestamps, and fractional inputs like 1700000000.5 are read as seconds with a sub-second remainder.

What the converter outputs

The output grid is the core of the tool. Every paste produces twelve cards, each with its own copy button:

  • Unix seconds — floored integer, the format most CLIs and log parsers want.
  • Unix milliseconds — full-precision integer, the format most JSON APIs want.
  • ISO 8601 (local) — full precision with explicit +HH:MM offset, so the string is self-describing without timezone metadata.
  • ISO 8601 (UTC) — the canonical Z suffix form, produced by toISOString() and what most databases store.
  • RFC 2822 — the comma-separated wire format used by HTTP Date headers, SMTP envelopes, and cookies.
  • Local (full) — verbose localised rendering with weekday, month name, and timezone abbreviation.
  • Local (short) — compact localised rendering suitable for dense UI.
  • UTC (full) — the same verbose rendering but pinned to UTC for comparison.
  • Relative to now — "2 hours ago", "in 3 days", "last week" using Intl.RelativeTimeFormat.
  • Day of week — "Monday", "Tuesday", etc. in your browser's locale.
  • Day of year — 1-based 1–366 integer, useful for cron expressions and annual rollups.
  • ISO 8601 week number — 1–53 integer following the standard ISO week rule (week 1 contains the first Thursday of the year).

Why this tool exists client-side only

Timestamps are often adjacent to things you should not paste into a server form. Session cookies, trace ids, auth tokens, and customer identifiers all tend to travel alongside the timestamp you are actually debugging. A server-side epoch converter gets a copy of every paste — its logs become a timeline of your debug sessions. This tool uses native Date, Intl.DateTimeFormat, and Intl.RelativeTimeFormat to compute every representation in the browser. There is no POST to format, no analytics on input content, and no third-party script sitting between your clipboard and the output. The Share button encodes your input into the URL fragment (#…), which browsers never send to servers by design, so shared links preserve the same privacy guarantee.

Y2K38 and other epoch landmarks

The Unix epoch has a handful of dates worth knowing when you are debugging a system that might break at one of them. 1970-01-01T00:00:00Z is the epoch itself — any timestamp of zero is either uninitialized state or a deliberately-zeroed default. 2038-01-19T03:14:07Z is the Y2K38 boundary, where int32 Unix seconds overflow. 2106-02-07T06:28:15Z is the unsigned 32-bit overflow, a common failure mode in embedded firmware that treats time_t as uint32. This converter handles all three without overflow because JavaScript's 64-bit Date backing survives well past the year 275000.

Related tools

  • UUID Generator — mint v7 time-ordered UUIDs that embed a Unix millisecond timestamp in the leading bits.

Frequently asked questions

What is Unix time and why do programmers use it?

Unix time is the number of seconds that have elapsed since 1970-01-01T00:00:00Z, the "Unix epoch". Because it is a single monotonic integer with no timezone, no DST, and no calendar edge cases, Unix time is the lingua franca of server logs, database timestamps, HTTP headers, JWTs, and wire protocols. This Unix timestamp converter turns those raw integers back into the human-readable dates you actually need to debug with.

What is the difference between Unix seconds and Unix milliseconds?

A Unix seconds timestamp has up to 10 digits today (for example `1700000000` for November 2023) and increments once per second. A Unix milliseconds timestamp has 13 digits (`1700000000000`) and increments once per millisecond. JavaScript's `Date.now()`, most JSON APIs, and modern logging pipelines emit milliseconds; older C-style APIs, Postgres `extract(epoch …)`, and many Unix CLIs emit seconds. This tool auto-detects which you pasted by counting the digits — 10 digits or fewer means seconds, 13 digits means milliseconds, 16 digits is microseconds, and 19 digits is nanoseconds.

What is the Y2K38 problem and does it affect this tool?

The Y2K38 problem — also called the "Unix millennium bug" — is the moment at 2038-01-19T03:14:07Z when a 32-bit signed integer holding Unix seconds overflows. Any system still using `time_t` as `int32` will wrap to a negative number and start reporting dates in 1901. This Unix timestamp converter uses JavaScript's 64-bit float-backed Date, so it handles timestamps far beyond 2038 without overflow — but it flags the boundary as a known landmark, because any embedded system or legacy C code you are debugging against may still break there.

How does this timestamp converter handle timezones?

All "local" outputs — local full, local short, ISO 8601 local — render in the timezone your browser reports via `Intl.DateTimeFormat`. All "UTC" outputs ignore your local timezone entirely and pin to the Z meridian. Relative phrasing ("2 hours ago") uses your local clock as the reference. Unix seconds and Unix milliseconds are inherently timezone-free — the integer is the same on every machine on earth. This design lets you paste an ISO string with a `+05:30` offset, an RFC 2822 date in GMT, or a raw integer and see all three representations side by side.

Why does this tool run entirely in my browser?

Server-side timestamp converters have to POST your input to a logging server that then returns the formatted output. For debugging production logs, session cookies, or user activity, that round-trip is unacceptable — the timestamps in your clipboard might embed PII-adjacent context. This converter uses native `Date`, `Intl.DateTimeFormat`, and `Intl.RelativeTimeFormat` to format every representation on-device. There is no network call, no analytics on your inputs, and no server log that sees your debug session.

Can I convert an ISO 8601 string back to Unix time with this tool?

Yes. Paste any ISO 8601 or RFC 3339 string — with or without a timezone offset, with or without fractional seconds — and the Unix seconds and Unix milliseconds fields appear immediately in the output grid. It also accepts the common "YYYY-MM-DD HH:MM:SS" format that spreadsheets and SQL queries emit (treated as local time), bare "YYYY-MM-DD" dates (treated as UTC midnight), and RFC 2822 / RFC 5322 wire dates like `Fri, 01 Mar 2024 12:34:56 GMT`.

Related tools