Unix Timestamp Converter

Convert a Unix timestamp to a human date (UTC, ISO, local, relative) — seconds or milliseconds auto-detected.

Seconds vs milliseconds is auto-detected by length. Conversions use your device's local timezone.

How to use the Unix Timestamp Converter

  1. Enter a timestamp. Paste a Unix epoch in seconds or milliseconds.
  2. Convert. See UTC, ISO, local and relative times.
  3. Or use now. Grab the current timestamp with one click.

Free to use — premium coming soon

FREE
  • Seconds/ms auto-detect
  • UTC/ISO/local/relative
  • 100% private
PREMIUM
  • Remove ads
  • Timezone picker & batch convert

About the Unix Timestamp Converter

The Unix Timestamp Converter turns a raw epoch number into a readable calendar date and time, and turns a date back into its epoch value. A Unix timestamp is simply the count of seconds that have passed since 00:00:00 UTC on 1 January 1970, the moment programmers call the Unix epoch. Because it is just an integer, it is the most compact and unambiguous way to store an instant in time. This tool reads both directions: paste a number to decode it, or pick a date to encode it, with output shown in UTC and your local time zone side by side.

Reach for this converter whenever you meet a bare number where a date should be. Server logs, API responses, JWT expiry claims, database columns, cookie expiry fields, IoT sensor records, and Git commit metadata all routinely store time as an epoch value rather than a formatted string. Developers, QA testers, support engineers, and data analysts use it to sanity-check that a token has not expired, to confirm a record was written when expected, or to build a query filter. It also helps when you need the current epoch value to hard-code into a test or a scheduled job.

Mechanically, conversion is plain arithmetic on a single counting axis. A 10-digit number is measured in seconds; a 13-digit number is in milliseconds, and one is converted to the other by multiplying or dividing by 1000 (JavaScript's Date.now() returns milliseconds, while most server languages return seconds). The tool detects the magnitude and offers both readings so you are never off by three orders of magnitude. Negative numbers are valid too and point to dates before 1970, counting backward one second at a time, so -86400 is exactly one day before the epoch.

Accuracy note: Unix time deliberately ignores leap seconds and treats every day as exactly 86,400 seconds, so the value tracks UTC rather than the Earth's exact rotation. As of late 2025, 27 leap seconds have been inserted since 1970, which is the small offset between Unix time and true elapsed atomic time. This converter runs entirely in your browser using your device's own date engine, so the timestamps you enter are never uploaded, logged, or sent to a server. Your local-time output reflects the time zone configured on your own machine.

Frequently asked questions

How do I tell if my timestamp is in seconds or milliseconds?

Count the digits. A timestamp for a recent date has 10 digits in seconds (e.g. 1700000000) and 13 digits in milliseconds (e.g. 1700000000000). Multiply seconds by 1000 to get milliseconds, or divide by 1000 to go the other way; this tool shows both readings automatically.

What time zone does a Unix timestamp use?

A Unix timestamp has no time zone of its own; it always represents a single instant measured from the epoch in UTC. Any local time you see is produced when the number is formatted for a particular zone, which is why this converter shows both the UTC value and your machine's local time.

What is the year 2038 problem?

Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is reached at 03:14:07 UTC on 19 January 2038. After that the value overflows and wraps to a negative number, misreading the date as 1901. Modern 64-bit systems store the value in a 64-bit integer and are not affected.

Can a Unix timestamp be negative?

Yes. Negative values represent dates before the epoch, counting backward one second at a time, so -86400 is 31 December 1969 at 00:00:00 UTC. They are mathematically valid, though some older systems and languages handle them poorly.

How do I get the current Unix timestamp in code?

In JavaScript use Math.floor(Date.now() / 1000) for seconds or Date.now() for milliseconds. In Python use int(time.time()), in PHP use time(), and in most SQL dialects use a function like UNIX_TIMESTAMP() or EXTRACT(EPOCH FROM now()).

From our blog

How to Read, Fix, and Shrink JSON: A Practical Formatter Guide

By the Super Simple Digital Tools Team · Updated June 2026

JSON is everywhere in modern development, but it almost never arrives in a form you can read. API responses, webhook payloads, and minified config files tend to be a single dense line, and the moment the structure gets nested more than a level or two, scanning it by eye becomes guesswork. A formatter solves the first half of the problem by re-indenting that line into a tidy tree where every key sits at the depth it belongs to. The second half, validation, tells you whether the text is even legal JSON before you waste time debugging the wrong thing.

Start by pasting your text and formatting it. If it beautifies cleanly, the JSON is well-formed and you can read off the structure: objects in curly braces, arrays in square brackets, and indentation showing what is nested inside what. If formatting fails, the tool stops at the first syntax error and tells you the line and column. That location is the fastest path to a fix, because JSON parsers fail at the exact character where the grammar breaks, not at the conceptual mistake somewhere above it.

Most validation failures come down to a short list of habits borrowed from JavaScript or Python. Trailing commas are the number one offender: a comma after the last array element or object property is fine in JavaScript but illegal in JSON. Single quotes are second; JSON requires double quotes for every string and every key, with no exceptions for simple alphanumeric names. Comments are third, since JSON has no comment syntax at all. Knowing these three rules resolves the large majority of the errors people hit when writing JSON by hand.

Once your JSON is valid, minification is the inverse operation. The tool walks the parsed structure and writes it back with no spaces, no newlines, and no indentation, producing the smallest faithful representation of the same data. This is what you want when embedding JSON in a query string, a single-line environment variable, or a request body where every byte counts. Because both directions work from the same parsed tree, you can beautify to inspect, edit, and then minify again without any risk of the formatting step altering your values.

One thing a formatter does not do is judge whether your JSON is correct for its purpose. Syntactic validity only means the text follows the grammar; it says nothing about whether a field is named the way your API expects, whether a date string is in the right format, or whether a number is within an allowed range. Those are semantic concerns, and they belong to JSON Schema validation or to your application's own checks. Treat the formatter as the first gate that catches broken syntax cheaply, then layer schema validation on top when correctness of content matters.

  • If validation fails, look at the line just above the reported position first; a missing comma or an unclosed bracket often shows up as an error on the next token.
  • When pasting an API response from DevTools or curl, beautify it immediately so deeply nested fields become easy to trace before you start editing.
  • Use minify for values you have to fit on one line, such as a JSON-typed environment variable or a config field, but keep a beautified copy for editing.
  • If you need trailing commas or comments for readability, you are working in JSON5 or JSONC, not JSON; strip them before sending the data to a strict parser.

Read the full guide →

Tool by the Super Simple Digital Tools Team. Reviewed by our editorial team. Free to use, no signup required.

Related tools