Timestamp Converter

Convert between various timestamp formats including ISO 8601, RFC 2822, Unix, Windows FILETIME, and more.

Tested tool guide Tested browser tools Checked August 16, 2026

What Timestamp Converter does, with a checked example

Paste a timestamp in any supported format - ISO 8601, RFC 2822, Unix seconds, Windows FILETIME, and others - and this tool returns the same instant rendered in every format it handles, so one paste yields the full conversion set. The first step is classification: digit count and structure decide what you pasted before any conversion runs. The thing users most often get wrong is timezone. An integer timestamp names an instant on the timeline, not a clock reading; the rendered time changes with the display zone, and text dates that omit a zone are inherently ambiguous. The other classic error: a 13-digit millisecond value read as seconds lands in the year 31,969.

Worked example

A concrete input and expected output from the current implementation.

Input

946684800

Expected output

ISO 8601: 2000-01-01T00:00:00Z | RFC 2822: Sat, 1 Jan 2000 00:00:00 +0000 | Unix seconds: 946684800 | Unix milliseconds: 946684800000 | Windows FILETIME: 125911584000000000

946684800 seconds is exactly 10,957 days after the Unix epoch, which lands on 2000-01-01T00:00:00Z, a Saturday; the weekday is computed from the date, not read from the input. The FILETIME value adds the 11,644,473,600 seconds between the 1601 and 1970 epochs and counts 100-nanosecond ticks.

How the result is produced

Format detection first

Every input is classified by shape before conversion. A bare integer with 10 digits is read as Unix seconds, 13 digits as milliseconds, a value near 1.16 x 10^17 as Windows FILETIME (100-nanosecond ticks since 1601-01-01 UTC), and anything containing letters or separators as a text date. The tool then resolves the input to a single instant and re-renders that instant in every other format. A date alone does not pin down an instant; without a zone suffix, parsing must assume one.

Rendering and timezone

All formats are rendered from that one resolved instant using their own grammar: ISO 8601 uses the T separator and a Z or +HH:MM suffix, RFC 2822 uses three-letter weekday and month names with a +HHMM zone, Unix is an integer count, FILETIME is the raw tick count. Display defaults to UTC, with a local-time view showing the same instant shifted by your local offset. That shift is why one input can legitimately read as two different clock times.

Good uses

A server log or API response returns 1767225600 and you need the calendar date and weekday for an incident report (it is 2026-01-01T00:00:00Z, a Thursday).
JSON exports carry ISO 8601 strings; converting them to Unix seconds gives your script a single numeric field to sort, filter, and compare.
Windows artifacts - NTFS file times, registry keys, .NET DateTime.ToFileTime output - arrive as huge FILETIME integers near 1.34 x 10^17; you need the human-readable date.

Limits and checks

Text dates without a timezone are ambiguous. 2024-03-01 12:00:00 carries no zone, so the tool must assume local time or UTC, and the two readings differ by your UTC offset. Append Z or an explicit +HH:MM to pin the instant.
Millisecond values are easy to misread. 946684800000 is milliseconds, meaning 2000-01-01T00:00:00Z; read as seconds it lands in the year 31,969. If a result is centuries off, check whether the input was 10 or 13 digits.
UTC display and local display show different clock digits for the same instant: 2000-01-01T00:00:00Z reads as 1999-12-31 19:00:00 -0500 in U.S. Eastern time. Compare zone suffixes, not the clock part.

Common questions

Why does my timestamp convert to a different time than the one in my log?

A bare integer is an instant, not a clock reading; the clock time shown depends on the display timezone. If your log stored UTC and you are viewing Eastern time, expect a five-hour difference, not an error. If your source logged local time, add its offset to the value before converting, or the instant itself is shifted.

What is Windows FILETIME, and why is the number so large?

FILETIME is Windows' native timestamp: the count of 100-nanosecond intervals since 1601-01-01 UTC. Present-day dates sit around 1.34 x 10^17, and the Unix epoch is exactly 116444736000000000. You meet it in NTFS metadata, the registry, and .NET's DateTime.ToFileTime; the tool converts it so you rarely need to handle the raw value.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

JSON Formatter & Validator

Format, validate, and beautify JSON with syntax highlighting and error detection.

Base64 Encoder / Decoder

Encode text or files to Base64 and decode Base64 strings back to their original form.

SQL Formatter & Beautifier

Format and indent SQL queries for better readability across all major dialects.

HTML to Markdown Converter

Convert HTML markup into clean Markdown syntax with support for tables and lists.

Markdown to HTML Live Preview

Write Markdown and see the rendered HTML output in real time with live preview.

Diff / Patch Viewer

Visualize unified diffs and patch files with color-coded additions and deletions.