The clock at the top of the bench never stops — it's the current Unix time, ticking one second at a time, right where you'll use it. Below it, two tools: a bidirectional timestamp ↔ date converter where editing either side updates the other, and an epoch decomposer that turns any moment into ISO 8601, UTC, local, RFC 2822, relative time, hex and binary. Seconds and milliseconds auto-detected, negative pre-1970 values welcome. Nothing is uploaded, nothing is stored.
The everyday workhorse, and it runs both ways. Type a timestamp — seconds or milliseconds, auto-detected by magnitude — and the date field, the readouts and the stat strip all resolve to that moment. Or pick a date and time and watch the timestamp appear. The two inputs stay in sync, so you never convert the same value twice. Negative values work too, so dates before 1970 are first-class citizens.
Example · a famous second
1234567890
↓
Fri, 13 Feb 2009 23:31:30 UTC
the moment geeks around the world raised a glass — 1234567890.
Use it for API debugginglog readingdatabase valuesscheduling
Drop in any epoch value and the bench tells you everything it knows about that moment: ISO 8601, the UTC and local renderings, RFC 2822 for mail headers, a plain-English relative reading, and — for the low-level minded — the value in hex and binary. The stat strip decomposes the whole span into days, hours, minutes and seconds since 1970. Quick chips jump to now, an hour or a day ahead, the Moon landing, or the stroke of Y2K.
Example · the starting gun
0
↓
1970-01-01T00:00:00.000Z · Thu, 01 Jan 1970 00:00:00 GMT · 0x0
the epoch itself — every count starts here.
Use it for forensicsfile metadataprotocol workteaching time
Time rules · the reference is 1970-01-01 00:00:00 UTC — the Unix epoch · values above 100 billion in magnitude are read as milliseconds, anything smaller as seconds · both readouts always show seconds and milliseconds, so the output is never ambiguous · UTC is the reference; LOCAL adds your timezone offset including the DST rule in force on that date · negative timestamps (pre-1970) convert, decompose and render in hex/binary just like positive ones · relative readings are computed against your machine's clock at the moment of rendering · the live clock at the top ticks in your browser — it never phones home
The privacy promise
Count anything. We couldn't see it even if we wanted to.
This page has no backend and no database. Every second counted, every date resolved and every hex digit emitted just now happened inside your own browser tab — your timestamps never traveled a single centimeter of cable. Even the live clock is yours: it ticks locally, and when you close the page it's gone for good.
TICKING SECONDS→COMPUTED IN YOUR BROWSER→EVERY FORMAT
✕ SERVER · DATABASE · LOGS · ANALYTICS
Databasenull
Backendnone
Time uploads0
Session logs0
Questions
Asked often, answered plainly.
( 02 )
What's the difference between Unix time and epoch time?
Nothing — they're two names for the same thing: a count of seconds since 1970-01-01 00:00:00 UTC, the Unix epoch. On this page the Unix Timestamp Converter focuses on going back and forth between a timestamp and a calendar date, while the Epoch Converter takes any value and decomposes it into every representation it knows — string formats, relative time, hex and binary.
Seconds or milliseconds — which does the bench expect?
Both, auto-detected. Values whose magnitude is above 100 billion are read as milliseconds — the convention JavaScript and many runtimes use — and anything smaller is read as seconds, the convention of most APIs, databases and operating systems. The readouts always show both, so there's never ambiguity in the output.
Why does my local time differ from UTC?
UTC is the single worldwide reference; your local time is UTC plus your timezone offset, including whatever daylight-saving rule is in force on that particular date — which is why the offset can be different in January than in July for the same place. The bench shows both side by side, and the LOCAL readout names the timezone abbreviation it used.
Can it handle dates before 1970?
Yes — timestamps before the epoch are simply negative, and the bench handles them throughout. Conversion, decomposition, hex and binary all work with negative values, so the Moon landing (around -14159020) converts just as cleanly as tomorrow. The quick chips on the Epoch tab let you verify with one click.
Is my data saved anywhere?
No. IrisTool has no backend and no database. Every conversion happens inside your browser tab and disappears the moment you close or refresh the page. There is nothing to leak, because nothing is ever collected.