Give two dates and see the gap in days, weeks, hours and in calendar terms. Two details are handled deliberately. The comparison is done in UTC, because a range that spans a daylight-saving change is 23 or 25 hours short of a whole number of local days and rounds to the wrong answer twice a year. And the calendar figure counts real months rather than dividing by thirty, so a month that starts on the 31st lands where you would expect.
This page loads no libraries at all — the work is done by the browser itself. Your file is read on your own machine and never sent anywhere — open your browser's network tab and watch while you use it.
Because local time is not a straight line. When the clocks change, one local day is 23 hours long and another is 25, so a difference measured in local time comes out a fraction short or long and rounds to a day either way. It happens twice a year, silently, and only on ranges that cross the change — which is exactly the sort of bug that survives testing.
By actually adding months and then counting the days left over, not by dividing by 30 or 30.44. Adding a month to the 31st is clamped to the last day of the shorter month, so 31 January plus a month is 29 February in a leap year rather than spilling into March. Without that clamp the answer comes out a day short, and an earlier version of this tool reported "1 month, −1 days" until the test caught it.
It adds one to the day count, which is what you want when the two dates are themselves working days — a task running Monday to Friday takes five days, not four. Left off, you get the plain interval.
Anything the browser understands, including 2026-03-01, 1 March 2026 and full ISO timestamps. A plain date with no time is read as midnight UTC so that the two ends are treated the same way.
Everything here is free and works the same way — in your browser.