Timestamp Converter Developer Tool
Convert between Unix timestamps and human-readable dates, in any timezone.
Reading a raw Unix timestamp out of a log line, an API payload, or a database column means doing the seconds-since-1970 math in your head, or more realistically, opening a REPL. This free timestamp converter is a developer tool that converts between a Unix timestamp and a human-readable date/time in both directions, entirely in your browser, and auto-detects whether a pasted timestamp is in seconds or milliseconds.
Unix timestamp
Human-readable
Runs entirely in your browser — no data is sent anywhere.
Unix time, briefly
A Unix timestamp counts the number of seconds that have elapsed since the "epoch" — midnight, January 1st 1970, UTC — with no leap seconds. It's a single, unambiguous integer rather than a formatted string, which is exactly why it's the default way most databases, APIs, and log formats store a point in time internally: no locale, no format string, no timezone parsing ambiguity, just a number that sorts and compares correctly. The trade-off is that the number is meaningless to a human without converting it, which is the entire reason a tool like this exists.
Seconds vs milliseconds
The classic Unix timestamp is in seconds (10 digits for dates in the current era, e.g. 1780000000), but JavaScript's own Date.now() and many JSON APIs use milliseconds instead (13 digits, e.g. 1780000000000) for finer precision. Pasting a 13-digit number where a system expects seconds — or vice versa — produces a date wildly in the past or the far future rather than an error, which makes it a surprisingly common and hard-to-spot bug. This tool detects which unit you've pasted by digit count and labels it accordingly, so it's worth a glance at the detected unit before trusting the converted date.
Timezones and why UTC matters
A Unix timestamp itself has no timezone — it's a fixed instant in time, the same integer everywhere on Earth. The timezone only enters the picture when converting that instant to a human-readable date and time, since "2026-01-01 00:00" means a different moment depending on whether it's interpreted in UTC, London time, or Tokyo time. Storing timestamps and doing internal date math in UTC, then converting to a local timezone only at the point of display, is the standard way to avoid an entire class of off-by-a-few-hours bugs. See the task scheduling guide's Timezones section for how this plays out specifically with Laravel's scheduler, and the Eloquent guide for how datetime columns get cast to timezone-aware Carbon instances automatically.
Common use cases
This conversion comes up constantly when debugging: an API response with a raw created_at: 1780000000 field, a JWT's exp claim, a log line stamped in epoch time, or a database row where a timestamp column is being inspected outside of the application that normally formats it. It's also useful in reverse — picking a specific future date and time and getting back the timestamp to hardcode into a test fixture, a scheduled job's target time, or an API request that expects epoch time as a parameter.