Skip to main content

Unix Timestamp ⇄ Date — Seconds, Milliseconds, ISO 8601

Unix timestamp ⇄ human date — seconds / milliseconds / ISO 8601 — UTC and local — browser-only

  • Runs locally
  • Category Calculator
  • Best for Getting a realistic range before a purchase, plan, workout, or schedule decision.
Current epoch

Timestamp → Date

Detected as: Seconds
UTC2026-06-14 06:06:23 UTC
Local2026-06-14 06:06:23 +00:00
ISO 86012026-06-14T06:06:23.000Z
Relativejust now

Date → Timestamp

What this tool does

Free online Unix timestamp converter. Paste a timestamp (seconds or milliseconds, auto-detected) to see UTC and local datetime, ISO 8601, and relative-from-now. Or paste any date string to get the timestamp. Live "current epoch" ticker. Handles negative timestamps (pre-1970). 100% client-side.

Tool details

Input
Text + Numbers
The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output
Live result + Copy
The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy
Browser-side processing
The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share
No account required
Open the page and use it; whether results survive refresh depends on the tool.
Performance budget
Initial JS <= 8 KB
No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit
Calculator · Developer
Category and role tags drive related tools, internal links, and quick fit checks.

How to use

  1. 1. Input

    Paste or drop your content into the tool panel.

  2. 2. Process

    Click the button. All processing is local in your browser.

  3. 3. Copy / Download

    Copy the result or download to disk in one click.

How Unix Timestamp Converter fits into your work

Use it for fast estimates, comparisons, and planning numbers before you make the final call.

Calculation jobs

  • Getting a realistic range before a purchase, plan, workout, or schedule decision.
  • Comparing scenarios by changing one input at a time.
  • Turning rough assumptions into a number you can discuss.

Calculation checks

  • Double-check units, dates, rates, and rounding assumptions.
  • Treat health, finance, tax, and legal outputs as planning aids, not professional advice.
  • Save the inputs that produced an important result so you can reproduce it later.

Good next steps

These links move the current task into a more complete workflow.

  1. 1 Date Difference Calculator Days / weeks / months / years between two dates — plus business-days mode — browser-only Open
  2. 2 JWT Decoder Decode JWT header / payload / signature — verify structure, check exp, copy claims — browser-only Open
  3. 3 Duration Converter Seconds ⇄ minutes ⇄ hours ⇄ days ⇄ weeks, plus human-readable, ISO 8601 duration and HH:MM:SS — one input, every format — browser-only Open

Real-world use cases

  • Debugging why a JWT "expired" 8 hours early

    A token's `exp` claim reads `1719820800` and your gateway rejects it as expired, but the wall clock says you have hours left. Paste it here: it resolves to Jul 1 2024 08:00:00 UTC, which is midnight in your `-08:00` zone, not the local 8am you assumed. The bug was reading the epoch as local time. Spotting the UTC-vs-local gap takes one paste instead of an hour of console.log.

  • Filtering a million-row log dump by a time window

    You need every event between "yesterday 14:30" and "15:00 local" but the logs store raw epoch seconds. Type the two human dates here, copy the two timestamps (say 1719847800 and 1719849600), and drop them straight into `WHERE ts BETWEEN 1719847800 AND 1719849600`. No timezone math in your head, and the relative-from-now line confirms you grabbed the right day before you scan 1M rows.

  • Catching a milliseconds-vs-seconds bug in a data import

    A CSV column has values like `1719820800000` and your loader stores dates in the year 56,489. Paste one value: the auto-detect flags it as milliseconds (13 digits), so the real instant is Jul 1 2024, not the far future. You divide by 1000 before insert. This 13-vs-10-digit slip is the single most common epoch bug, and one paste shows it instantly.

  • Reading a negative timestamp from a legacy system

    An old mainframe export has a birthdate stored as `-2208988800` and every modern parser chokes or returns 1970. Paste it here: negative epochs are handled, so it resolves to Jan 1 1900 00:00:00 UTC. Now you know the system used a pre-1970 epoch and you can shift it correctly instead of guessing why 12,000 records show as "Dec 31 1969".

Common pitfalls

  • Treating a 13-digit value as seconds: `1719820800000` read as seconds lands in the year 56,489. If the number is 13+ digits, it's milliseconds — divide by 1000 (or use the unit toggle here to confirm).

  • Assuming the epoch is local time: `1719820800` is always UTC. In a `-05:00` zone it displays as 4am the previous-feeling day, not midnight — always check the UTC column before you subtract hours.

  • Hand-typing 'now' as a constant: copying a stale `1719820800` into a test fixture rots fast. Use the live current-epoch ticker here so your 'now' is actually now, not last Tuesday.

Privacy

All conversion runs in your browser via the native `Date` API; no timestamp, date string, or timezone ever leaves your machine or hits a server. The value you paste — including the JWT `exp` claims or log timestamps you may be debugging — stays in the tab. The unit toggle and timezone are read locally too. Nothing is logged or transmitted.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Browse all tools for this role
Made by Toolora · 100% client-side · Updated 2026-06-14