"Epoch" is just a fancy word for "starting line." Pick a moment, call it zero, and count forward from there. Theη΅θδΈ most important one β and unless you're living in a very specific corner of Windows internals, the one you care about β is January 1, 1970 at 00:00:00 UTC. That's the Unix epoch, and everything measured in "Unix time" is just the number of seconds that have elapsed since then.
You'll see the concept everywhere once you know to look for it. When you decode a JWT in your browser devtools and see "exp": 1718265600, that's epoch seconds. When Python's time.time() gives you 1718265600.147, that's epoch seconds with decimals. When a microsecond-precision logging library writes 1718265600147123, that's epoch microseconds. Different units, same reference point β and mixing them up is one of those bugs that doesn't produce an error, just a date that's silently wrong by a factor of a thousand.
It's worth understanding why 1970 specifically. Early Unix used a 32-bit integer to store time for memory efficiency. The engineers picked January 1, 1970 as the epoch because it was a recent, convenient round-ish boundary and the operating system hadn't existed before then anyway. A 32-bit signed integer counting seconds gives a range from roughly 1901 to 2038 β enough headroom in 1969 to not think hard about it. That assumption mostly held. Mostly.
This tool exists because translating between epoch and a readable date by hand is tedious and error-prone. Drop in an epoch value (seconds, milliseconds, microseconds, or nanoseconds β the length of the digits tells the tool which you mean) and you get the corresponding calendar date in UTC, in your local timezone, and in ISO 8601. The reverse works too: pick a date and time, and you get the epoch value for that instant β handy for pre-populating JWT fixtures or constructing WHERE clauses.
Beyond the basics, it surfaces information most converters skip: whether the date falls inside a DST transition window (when the same local wall-clock time can correspond to two different UTC instants), the day of the week, the ordinal day of the year, and whether the year is a leap year. That last one matters more than you'd think β two "identical" February dates in leap and non-leap years produce different epoch values, and fiscal-year calculations get confused by the extra day with depressing regularity.
Common moments this pulls its weight: verifying that the JWT exp claim is set to what you think it is (auth bugs live here), comparing epoch values from a Python backend to millisecond values from a JavaScript frontend during integration debugging, converting a database dump of epoch numbers into a human-readable audit trail, sanity-checking cron or Celery task ETA fields that are stored as epoch, and building quick-and-dirty time-series queries like "give me all rows where ts > [epoch for 7 days ago]."