What the Cron Field Decoder Does
This tool takes a five-field cron expression and breaks it back down into its named fields. You paste something like */15 9-17 * * 1-5 and get back a labelled list: which value belongs to the minute field, which to the hour, which to day-of-month, month and day-of-week.
One point must be stated plainly, because the tool's name overpromises. It does not generate a regular expression. It decodes and labels the fields, and it says so in its own output — the result explicitly notes that cron fields are not regular and that a true regex cannot express rules like last Friday, directing you to use the decoded breakdown to build a pattern for your specific case.
Used that way it is genuinely useful. The most common cron mistakes are not mechanical failures but misinterpretations — reading the day fields in the wrong order, or assuming that restricting day-of-month and day-of-week will intersect when the customary behaviour is to unite them. Having each field named and separated in front of you is an effective guard against both.
How the Decoding Works
The implementation is a splitter and a labeller. The input is trimmed and split on runs of whitespace into up to five parts, and each part is printed against its field name in the conventional order.
If the input contains fewer than five whitespace-separated parts, the tool refuses with a message explaining that a cron expression has five fields — minute, hour, day-of-month, month, day-of-week. That guard is the tool's main piece of validation. Anything beyond five fields is not rejected; the split simply produces more parts, and the first five are the ones labelled.
What the decode does not do is interpret the field contents. It does not expand ranges into the set of values they represent, does not evaluate step syntax, does not tell you what day of the week a given day-of-week number is, and does not check that a value falls inside its field's legal range. A 99 in the minute field is labelled as a minute and passed through without complaint, even though no cron implementation would accept it. The output is a structural breakdown, and validating the numbers is your job.
The refusal to emit a regex is a correctness decision rather than a limitation to be worked around. Cron schedules express ordinal and positional constraints — the third Friday of the month, the last weekday before a given date — which depend on counting within a span whose length varies. Deterministic finite automata cannot count, so a general translation is not possible. It is true that for any fixed calendar range you could construct a regex that matches exactly the timestamps that range produces, but such a pattern would be enormous, tied to specific years, and useless the moment the range moved.
Using the Decoder
- Step 1 — Paste the cron expression into the input area. Include all five fields, separated by spaces. Cron tolerates multiple spaces, and so does this tool, since it splits on runs of whitespace.
- Step 2 — Run the transform. There are no options, flags or timezone settings. The output is purely a field-by-field reading of the text you supplied.
- Step 3 — Check the field count. A message saying a cron expression has five fields means your input was too short — often because the expression was truncated on copy or because you pasted only the time-related fields.
- Step 4 — Read the labelled breakdown against the field meanings. The output names each field in order and prints its value, then repeats the caveat about regularity. Use it to confirm that the value you meant as the day-of-week is in the day-of-week position and not the day-of-month position.
- Step 5 — Validate the values yourself. The decode does not range-check. Confirm minutes fall in 0–59, hours in 0–23, day-of-month in 1–31, month in 1–12, and day-of-week in 0–7 — and decide explicitly whether
0 or 7 is Sunday in your scheduler, because implementations vary.
Common Use Cases
Reviewing a schedule before it goes live. Job schedules are configured once and then left alone, which is exactly the situation where a misplaced field becomes a silent five-minute-interval job instead of a nightly one. Reading the labelled fields back is a cheap check before committing.
Debugging a job that runs at the wrong time. When a task fires more or less often than expected, the first question is which field holds the value you intended. The decode answers that structurally, without requiring you to recall the field order from memory.
Translating a schedule between systems. Moving from a traditional five-field scheduler into a Kubernetes CronJob or a CI pipeline raises questions about field count, about whether seconds are supported, and about which day-of-week numbering applies. Seeing the five labelled fields is the starting point for reconciling those differences.
Worked Example
Paste a realistic weekday schedule:
*/15 9-17 * * 1-5
The decode echoes the expression and labels the five fields: minute */15, hour 9-17, day-of-month *, month *, day-of-week 1-5. It then restates that cron fields are not regular and suggests using this breakdown to construct a pattern for your own case.
Reading those fields is where the value lies. The minute field uses a step: every fifteen minutes within the hour, so at :00, :15, :30 and :45. The hour field is a range from 9 to 17 inclusive — and note that this includes 17, so the final run of the day starts at 17:45 rather than 17:00, which is a common off-by-one-hour surprise. Both day fields are unrestricted, meaning every date qualifies. The day-of-week range 1-5 selects Monday through Friday under the customary numbering where 0 is Sunday.
Now the trap. Change the expression to 0 0 1 * 1 — the first of the month, and Mondays. Almost everyone reads that as the first of the month only when it is a Monday. In the customary cron behaviour the two day fields are combined with or, not and: the job runs on the first of every month, and on every Monday, because whenever both day fields are restricted each is treated as a separate trigger condition. If you genuinely need the intersection, you have to express it in your application logic rather than in the schedule. The decoder will not warn you about this, which is why the field meanings are worth knowing rather than just recognising.
Tips and Common Mistakes
- Remember the field order. Minute, hour, day-of-month, month, day-of-week. Reversing the last two is the single most common scheduling error, and the labelled output is designed to make that reversal obvious.
- Watch the day-of-month and day-of-week or rule. When both are restricted, conventional cron runs the job when either matches. If you need both, use a wider schedule and gate it in code.
- Know your day-of-week numbering.
0 is usually Sunday with 7 accepted as an alias, but some schedulers use 1 for Sunday. Confirm against your own platform before shipping. - Count the fields. Five is standard for traditional cron. Some implementations accept six with a seconds field or a leading year, and the boundary between the two conventions is a frequent source of jobs that fire far too often.
- Step values include both ends.
9-17 with a step of one includes 17. Ranges are inclusive, so the last run of the day is later than intuition suggests. - Schedules are timezone-dependent. This tool decodes fields and says nothing about timezones. An expression means different wall-clock times depending on the server's timezone, and daylight-saving transitions can cause a job to run twice or not at all.
- Check whether seconds are supported before using a sixth field. Some schedulers interpret six fields as seconds-first rather than minutes-first, which silently shifts every part of the schedule.
- Validate the numbers separately. The decoder does not range-check fields, so an out-of-range value is labelled and passed through rather than flagged.
Frequently Asked Questions
Does this tool convert a cron expression into a regular expression?
No. It decodes the expression into its named fields and states that cron fields are not regular. The name is misleading on this point. A general conversion is not possible, because constraints such as the third Friday require counting within spans of varying length, which finite automata cannot do.Why do I get a message about needing five fields?
Because fewer than five whitespace-separated parts were supplied. The expression was probably truncated when copied, or only the time fields were pasted. Check the source and paste the complete expression.Does the decoder expand ranges and steps?
No. It labels each field and prints its value as written. It does not expand 9-17 into twelve hours, does not evaluate */15, and does not verify that anything falls inside its legal range.How do I check whether my expression is actually valid?
Compare each decoded field against its documented range — minutes 0–59, hours 0–23, day-of-month 1–31, month 1–12, day-of-week 0–7 — and then confirm against the scheduler you are actually targeting, since implementations differ on special characters and numbering. This tool deliberately does not validate.Related Tools
If you need to match timestamp strings rather than schedule them, the
Regex Cheatsheet Search returns an ISO date recipe and the
Regex Tester will confirm what it matches and captures. To understand the tokens in any pattern you build from this breakdown, the
Regex Cheatsheet covers the syntax, and the
Regex Explainer inventories the constructs present in a pattern you paste.
Privacy & Security
This tool runs entirely in your browser — no data ever leaves your device. There is no server round-trip, no upload, no logging, and no account required. Your input is processed locally using client-side JavaScript and is never stored, transmitted, or accessible to anyone else. When you close the tab, everything disappears.