Timestamp Converter
Turn a Unix timestamp into a readable date - and back. You get seconds, milliseconds, ISO 8601, UTC, local time, the weekday, an RFC 2822 string and a
Convert between Unix timestamps and readable dates, in both directions and in both seconds and milliseconds. Paste 1735689600 or 2026-01-01T00:00:00Z and see the equivalent in UTC, in your local time zone and in common formats such as ISO 8601 and RFC 2822.
This comes up constantly when reading logs, debugging an API that returns epoch seconds, or checking that a token expiry is what you think it is. The conversion is exact and runs locally, and it warns you when a value looks like it is in milliseconds rather than seconds.
How to convert a Unix timestamp
Paste a timestamp or a date
Read the converted values in UTC and local time
Copy the format you need
FAQ
Seconds or milliseconds?
Ten digits is usually seconds, thirteen is usually milliseconds. The tool detects the likely unit and lets you switch it if the result looks wrong.
What is the Unix epoch?
The count of seconds since 1 January 1970 00:00:00 UTC, not counting leap seconds. It is the standard way to store a point in time.
Which time zone is used?
Both are shown: UTC and your browser local time zone, so you can compare what the server logs with what you see on the clock.
Does it handle dates before 1970?
Yes, negative values represent dates before the epoch, and far-future dates work up to the limits of the JavaScript date range.
Can it produce a timestamp for a date?
Yes, the conversion works in both directions - enter a date and get the epoch value.
Is anything uploaded?
No, the conversion is local arithmetic.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.