Cron Expression Parser
Decode a cron expression into readable fields, a plain-English description and upcoming run times.
Cron expressions are terse by design, and reading one back is a small skill: */15 * * * * is obvious once you know it, but 0 0 1,15 * 1 stops most people cold. This parser decodes any standard five-field expression into its five named fields, explains the schedule in plain English, and lists the next five times the job will fire.
Paste an expression from a crontab, a CI config or a scheduler, and press Parse. The minute, hour, day of month, month and day of week fields are each expanded into the concrete values they select - lists, ranges and steps resolved - so you can verify the schedule field by field.
The next five runs are computed from the current moment, which turns abstract syntax into a concrete "this job fires at 14:30 on Thursday" answer. Everything runs locally in your browser; the expression is never uploaded.
Format: minute hour day-of-month month day-of-week (0 or 7 = Sunday). Supports *, lists, ranges and steps.
Features
- Parses all five fields of a standard cron expression.
- Expands lists, ranges and step values into the concrete set each field selects.
- Plain-English description of the overall schedule.
- Next five run times computed from the current moment.
- Clear error messages for malformed or out-of-range fields.
- Handles 0 or 7 as Sunday, matching common cron dialects.
- Fully offline - nothing leaves your browser.
How to Use
- 1
Paste the expression
Enter any five-field expression such as 0 9 * * 1-5 into the input box.
- 2
Parse
Press Parse. Each field is expanded into its concrete selected values and shown in a breakdown card.
- 3
Read the description
A plain-English sentence describes the full schedule, so you can confirm it means what you think.
- 4
Preview the runs
The next five execution times appear, computed from the current moment in your browser zone.
Example
A tricky expression
0 0 1,15 * 1↓
Minute 0 · Hour 0 · Day of month 1, 15 · Month * · Day of week Mon → runs on the 1st and 15th, and every MondayFrequent schedule
*/5 * * * *↓
Minute every 5 · others any → runs every 5 minutes, all dayCommon Problems
Field order confusion
The five fields are minute, hour, day of month, month and day of week - in that order. A common mistake puts month and day of month backwards, which the parser surfaces field by field.
Day-of-week starting on Monday
Some systems count the week from Monday (1), others from Sunday (0 or 7). This parser follows the 0/7-is-Sunday convention used by most Unix crons and shows the day names explicitly.
The day-of-month OR day-of-week trap
When both fields are restricted, standard cron treats them as an OR. The parser explains the combined rule so you can spot schedules that fire more often than intended.
Out-of-range values
Values outside 0-59 for minutes or 1-31 for days of the month are invalid. The parser reports the offending field with a clear message instead of guessing.
Six-field expressions
Expressions that start with a seconds field are a different dialect. This parser expects five fields and will report the mismatch, steering you to the correct form for your scheduler.
Timezone in run previews
The next-run list uses your browser zone. On a server, the same expression is interpreted in the server zone, so run times can differ by the offset when zones are misaligned.
Names instead of numbers in the day field
Some dialects accept names like MON or abbreviations. This parser expects numeric day-of-week values (0-7); if you paste a named form, convert it to numbers first.
The L in day-of-month
Some schedulers support L (last day of month) in the day-of-month field. That is a dialect extension; this parser follows the standard numeric grammar and will report L as malformed.
Escaping the expression in shell contexts
When an expression passes through a shell, the * can be expanded by globbing. Quoting the expression prevents that; the parser itself receives the five fields after shell processing.
Technical Details
The parser tokenizes the five whitespace-separated fields and validates each against its allowed range, accepting single values, lists, ranges, steps and asterisks.
Each field expands into the concrete numeric set it selects - a range 1-5 becomes {1,2,3,4,5} - which is what the breakdown cards display.
Day-of-week 7 is aliased to 0 (Sunday), matching the dominant Unix cron convention. The expanded view shows canonical day names for the selected indices.
Run-time computation honors the day-of-month/day-of-week OR rule used by standard cron: when both fields are restricted, a date qualifies if either matches.
Expansion uses the same numeric set that run-time matching uses, so the breakdown cards and the next-run preview always agree with each other field for field.
Ranges and steps are normalized to their concrete values in the breakdown, which makes a range like 9-17 in the hour field readable as the nine distinct hours it selects.
The parser is strict about field count: exactly five fields are accepted, and anything else - trailing spaces included - is rejected with a precise message rather than silently misread.
Parsing and run computation run entirely in the browser, locally and synchronously. No expression is transmitted, stored or logged.
Frequently Asked Questions
What cron dialects does this support?
The standard five-field form with lists, ranges, steps and asterisks, and day-of-week 0 or 7 for Sunday - the convention used by Vixie cron, systemd timers and most CI schedulers.
Why does my expression show an error?
Either a field is out of range (a minute of 75, a month of 13), a value is malformed, or the expression has the wrong number of fields. The parser names the exact field at fault.
How does it handle day-of-month plus day-of-week?
Standard cron ORs them: the job runs when the day-of-month matches or the day-of-week matches. The description spells out the resulting union so nothing is ambiguous.
Are the next-run times in my time zone?
Yes - the preview is computed from your browser's local time, matching how the expression will be interpreted on a machine in the same zone. Zone differences between browser and server are the usual cause of "wrong" previews.
Does this tool save my expression?
No. The expression is parsed entirely in your browser and nothing is transmitted, stored or logged. You can paste production config with confidence.
Can it explain a seconds-based expression?
No - this parser expects the standard five-field form. A six-field expression that starts with seconds is rejected with a clear message, pointing you to the correct dialect.
Why does my named weekday not parse?
This parser accepts numeric day-of-week values 0-7 only. Dialects that accept MON, TUE and friends are a separate extension; convert the name to its number before parsing.
Data & Privacy
Your data stays in your browser. Nothing is uploaded.
- Processing
- Local
- Upload
- None
- Server Storage
- None
- Account
- Not required
Related Tools
Unix Timestamp Converter
Two-way Unix timestamp conversion between epoch seconds and human-readable dates.
Time & Date
Cron Expression Generator
Assemble a cron expression from field selectors with a live description and next-run preview.
Time & Date
Timestamp Generator
Turn a chosen date and time into every common timestamp format at once.
Time & Date
JSON Formatter
Format, validate and beautify JSON directly in your browser.
JSON & Data
Regex Tester
Test regex patterns against your text with live highlighting, capture groups and common-pattern shortcuts.
Regex & Text
Text Diff Checker
Line-by-line text comparison that shows every added, removed and unchanged line.
Regex & Text