Paste a five-field cron line and get each field spelled out, followed by the next few times it will actually fire. The runs are found by walking forward minute by minute rather than by a formula, which is slower and much harder to get wrong. It also watches for the trap in the specification: when both the day-of-month and the day-of-week fields are restricted, cron runs when either matches, not both.
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.
If both the day-of-month field and the day-of-week field are set to something other than a star, cron fires when either one matches. So 0 0 1 * 1 runs on the first of every month AND on every Monday, not on Mondays that happen to be the first. Almost everyone reads it as AND, which is why a job that was meant to run monthly quietly runs weekly as well. When your expression hits this case, the result says so.
By stepping forward one minute at a time from now and testing each minute against the expression, up to a year ahead. It is a brute-force method, and that is deliberate: the clever version has to encode every interaction between the fields, including the OR rule and the varying length of months, and it goes wrong in ways that are hard to see. If nothing matches within a year, you are told that too.
The standard five fields — minute, hour, day of month, month, day of week — with stars, lists, ranges and steps, so */15, 1-5 and 0,30 all work. Month and weekday names such as jan or mon are accepted, and 7 is taken as Sunday alongside 0, which is the common extension. Special strings like @daily are not.
UTC. Cron on a server runs in that machine’s time zone, which is often UTC and sometimes not, so the safest thing a browser tool can do is state one zone plainly rather than assume yours matches the server’s.
Everything here is free and works the same way — in your browser.