Cron Expression Parser

How To Use

1. Pick a dialect that matches your scheduler. The default is cron-parser, but you can switch to Standard, Spring, Quartz, or Hangfire/NCrontab — the same expression is then read the way that framework reads it.
2. Type or paste a cron expression. 5 fields are always minute hour day-of-month month day-of-week; 6 / 7 fields add seconds or a trailing year depending on the dialect (see the table below).
3. Click Parse to decode the expression. You get a place to switch dialects, a plain-English summary, a line for each field, the timezone (UTC), and the next 10 execution times.
4. Click Copy next times to copy the execution list to your clipboard.
5. If the expression is invalid, a clear error tells you which field and value are wrong.

Dialects and Field Layouts

Different schedulers interpret cron differently, most confusingly the day-of-week numbering and whether the 6th field is a leading second or a trailing year. This tool normalizes everything to one internal model, so the computed times and the plain-English description are always correct for the dialect you selected.

The day-of-week offset is the most common source of bugs: the same token 1-5 means Monday–Friday in Standard/Spring/Hangfire, but Sunday–Thursday in Quartz (where 1 is Sunday). This tool applies that offset for you automatically.

Usage Example

With the default cron-parser dialect, 0 9 * * 1-5 means “at 09:00, Monday through Friday”. Select the Quartz dialect and the same five fields read as a leading minute/hour with day-of-week 1-5 = Sunday–Thursday.

Trying */5 * * * * returns the summary “Every 5 minutes” followed by ten run times spaced exactly five minutes apart. Because the computation is local and deterministic, you can rely on the output being immediate and consistent across runs.

Frequently Asked Questions

What is the difference between 5-field and 6-field cron expressions?

The standard grammar has five fields: minute, hour, day of month, month, and day of week. The meaning of an extra sixth field depends on the dialect: in cron-parser (the default) a sixth trailing field limits the schedule to a single year — for example 0 9 * * 1-5 2027 runs every weekday at 09:00 only during 2027. In Spring, Quartz, and Hangfire/NCrontab, a sixth field is a leading second — 0 30 9 * * * runs at 09:30:00. Quartz additionally supports a seventh trailing year field: 0 0 9 * * 1-5 2027.

Why is Quartz’s day-of-week different?

Quartz numbers days of the week 1–7 where 1 is Sunday and 7 is Saturday. Most other flavors use 0–7 where 0 (or 7) is Sunday. So 1-5 means Monday–Friday in Standard/Spring/Hangfire but Sunday–Thursday in Quartz. This tool applies the correct mapping for the dialect you pick, so descriptions and computed times are always right.

What is @daily?

@daily is a shortcut meaning 0 0 * * * — once per day at midnight (00:00). Dialects that support seconds expand it to 0 0 0 * * * (seconds = 0). The parser also understands @hourly, @weekly, @monthly, and @yearly (and @annually), and expands them before decoding.

Why can't some Daily time sets be expressed as one expression?

The Daily preset lets you add several time points at once, but cron's minute and hour fields are independent, so a single expression can only represent the full Cartesian product of your minutes and hours. For example, wanting 09:00 and 18:30 would need minutes {0,30} and hours {9,18}, which would also run at 09:30 and 18:00 — times you didn't intend. When your time points don't form that complete minute×hour set, the generator reports that they can't be expressed as a single expression. Either pick points that form a complete combination, or use the Custom input (or multiple expressions) for irregular schedules.

When do ? and L matter?

In cron, * means "every value" in a field, while ? is an alternative used in the day-of-month or day-of-week fields to mean "no specific value". Here ? is treated as * for convenience. The L marker (last day of the month, e.g. 0 0 0 L * ?) is Quartz-only and is preserved in the field-by-field output.

Why only the next 10 run times?

Ten upcoming executions are enough to validate a schedule and spot mistakes without drowning in a long list. For minute-level schedules the sequence repeats predictably, so a short window is all you need. The times shown are the next ten strictly after the current moment.

What timezone is used?

All computation is done in UTC to keep results deterministic and unambiguous, and the output is labeled clearly. If you need local time, convert the displayed UTC times to your own zone. This documented behavior means the same expression produces the same run times for every visitor.

Is my expression uploaded to a server?

No. Everything runs locally in your browser. Your cron expression never leaves your device — there is no network request and no backend, so it is safe to paste sensitive or internal schedules.