You have a long number where a date should be. Paste it into the epoch converter below and you get the date back, in your own timezone and in UTC, along with the current timestamp ticking at the top.
And if a timestamp has ever given you a date in 1970 or one somewhere around the year fifty thousand, do not worry, you have not done anything stupid. You hit the one trap this whole subject has, and it is explained first because it is the thing worth knowing.
Nothing you paste leaves your browser. It all happens on your own computer.
Converted in your browser. Nothing is uploaded, and nothing is stored.
Seconds or milliseconds, the mistake everybody makes
These two numbers are the same moment:
1735689600 seconds since 1970
1735689600000 milliseconds since 1970Both mean midnight on 1 January 2025. The trouble is what happens when one goes into something expecting the other, because you do not get an error. You get a confident, wrong answer.
- Seconds read as milliseconds gives you a date in January 1970.
- Milliseconds read as seconds gives you a date tens of thousands of years from now.
I checked both rather than taking it on trust. The second one really does land past the year fifty thousand.
Most converters put a dropdown on the page and let you pick, which means they let you pick wrong. This one works it out from how many digits the number has and tells you which it decided, so you can see at a glance whether it guessed the way you meant.
Where it stops, and it is honest about this one. Eleven digits is genuinely ambiguous. Ten digits or fewer cannot sensibly be milliseconds, twelve or more cannot sensibly be seconds, but eleven could be either. When that happens it says so, shows you what each reading would mean, and lets you force it.
A timestamp has no timezone, and that is the other half of the confusion
This one causes arguments in offices.
A Unix timestamp is a count of seconds since a fixed instant. It means the same moment everywhere on earth. There is no timezone in it and there never was.
What changes is the date you read off it. The same number is Monday evening in London and Tuesday morning in Sydney. Neither is wrong. They are the same moment described by two people standing in different places.
Think of it like the moment a firework goes off. Everybody sees it at once. What they write in their diary about when it happened depends entirely on which clock they looked at.
So this page always shows both, labelled: your own timezone with its name on it, and UTC. A converter that shows one date without saying which zone it is in has thrown away the thing you actually needed to know.
The 2038 problem, which is real and closer than it sounds
Older systems store time in a 32 bit signed number. The largest it holds is 2147483647, and that runs out at 03:14:07 UTC on 19 January 2038.
One second later it wraps round and the system thinks it is 1901.
Anything modern uses 64 bits and is fine for longer than the sun has left. What is not fine is old embedded hardware, old databases, and systems nobody has looked at in fifteen years. Anything working with dates in the 2030s can trip over it today, not in 2038, because a mortgage or a pension is already storing dates past that line.
The tool tells you when a timestamp is close to that boundary, so if you are testing something you know to look at it.
Frequently asked questions
Is my timestamp sent anywhere?
No. It runs in your browser and there is no upload of any kind. Open your browser’s developer tools, go to the Network tab, and paste something in. Nothing is sent. You can also disconnect from the internet and it carries on working, ticking clock and all.
Can it handle dates before 1970?
Yes. A negative timestamp counts backwards, so -2208988800 is the start of 1900.
It is worth flagging when you use one, because a surprising amount of software either refuses negative timestamps or gets them quietly wrong. If you are storing a birth date this way, test it rather than assuming.
Why does my database show a different time from this?
Almost always the timezone, and almost always the database is set to UTC while you are reading it as local.
Compare the UTC row on this page with what the database shows. If they match, the number is fine and only the display is confusing you. If they do not, something has converted the timezone twice, which is a genuinely common bug and a much harder one to find.
What about leap seconds?
Unix time pretends they do not exist. Every day is treated as exactly 86,400 seconds even though a few real days have had an extra one added.
This means a Unix timestamp is not a true count of seconds elapsed since 1970, and it is out by a few dozen. For everything except satellites and physics it makes no difference at all, and every tool on earth does the same thing, but it is worth knowing that the number is a convention rather than a measurement.
If you have any issues, you can ask me via comment, and I will love to help you out.