Date Format on Your CV: What ATS Actually Prefers

A recruiter reads your CV. The ATS parses it. Those are two different operations, and dates are where they diverge the most. A human glances at "2021 - 2023" and moves on. A parser has to turn that string into two real points in time, and if it guesses wrong, the number attached to your profile is wrong for the rest of the process.

Search results for date format CV ATS are full of contradictory advice. The mechanism underneath is actually simple, and once you understand it the correct choice is obvious.

What the parser is actually doing with your dates

Your dates are not decoration sitting next to a job title. They are the raw input for three computed fields:

• Total experience, summed across every role on the CV
• Tenure per role, meaning how long you stayed in each one
• Gaps, meaning the unexplained months between one end date and the next start date

Recruiters do not eyeball those numbers. They filter on them. A search for "5+ years experience" in the ATS does not scan your bullet points for the word "years" - it queries the total experience field the parser calculated when your file was ingested. If your dates parsed badly, you are not ranked lower. You are absent from the result set.

That is the whole reason this narrow question matters. Everything else on your CV influences a human. Your dates influence a database query.

The two safe formats

There is no single ATS date format preferred by every vendor, but there are exactly two formats that every mainstream parser handles reliably:

• 03/2021 - 08/2024
• Mar 2021 - Aug 2024

Month and year. Nothing else. Both give the parser the two values it needs. Pick one, then use it on every single line of the CV.

Why year-only dates quietly cost you

Writing 2021 - 2023 looks clean. It is also the most expensive shortcut on this page.

A parser that receives only a year has to assume something. Common behaviour is to assume January of the start year and January of the end year, or to treat both as mid-year defaults. Either way you are handing the system a rounding error. A role you held from February 2021 to November 2023 is nearly 34 months. Parsed as 2021 - 2023 it can be counted as 24. Repeat that across four roles and you can lose a full year of computed experience, which is exactly the amount that decides whether you clear a "5+" filter.

There is a second cost. Experienced recruiters read year-only dates as a hiding tactic, because it is the standard way people conceal a four-month role or a nine-month gap. You get penalised twice: by the machine that undercounts you, and by the human who assumes the worst. Use year-only dates for nothing, not even for old roles.

The ambiguity trap: never write the day

03/04/2024 means 3 April in most of Europe and March 4 in the United States. The parser does not know which convention you were raised on. It applies whatever locale rule it was configured with, and if that guess is wrong your start date shifts by up to eleven months.

This is precisely why day-level precision is pointless on a CV. Nobody hiring you cares that you started on a Tuesday. Drop the day entirely and the ambiguity disappears with it, because 03/2024 can only be March 2024.

If you write months as numbers, always pad to two digits and always use a four-digit year: 07/2019, not 7/19.

Consistency matters more than which format you chose

Both safe formats work. Mixing them is what breaks things.

A CV that says Mar 2021 - Aug 2024 in one entry, 03/2021 - 08/2024 in the next, and March 2021 to August 2024 in a third forces the parser to re-detect the pattern on every line. Detection is usually done per document, not per line, so the entries that do not match the detected pattern are the ones that fail. They come back empty, or they inherit a date from the entry above.

Choose your format once, apply it to work history, education, certifications and volunteering, and never make an exception for a single line because it looked nicer.

Writing your current role

For an ongoing job you have three common options, and they are not equally safe:

• Mar 2023 - Present - safest, recognised almost universally
• Mar 2023 - Current - usually fine, slightly less common
• Mar 2023 - to date - riskier, less consistently mapped

Use Present. Avoid leaving the end open with a trailing dash (Mar 2023 -), because an empty end value can be read as a parse failure rather than an ongoing role. Avoid writing Mar 2023 - Now or putting today's date there, which makes the role look finished.

Separator and spacing

Use a plain hyphen with a space on each side: Mar 2021 - Aug 2024.

En dashes and em dashes often survive the trip, but they are also the characters most likely to be mangled by a PDF text extraction, and a broken separator turns two dates into one unreadable string. Slashes as separators (2021/2024) are worse - they collide with the numeric month format. A hyphen with spaces is the boring, safe choice. The word to also works, but only if you use it everywhere.

Abbreviated or full month names

Both parse. Jan, Feb, Mar, Sep and so on are standard three-letter abbreviations, and Sept is also fine. Full names like January parse equally well and simply take more space.

Do not invent abbreviations, do not add a period on some months and not others, and do not capitalise inconsistently. If you abbreviate one month, abbreviate all twelve.

Applying in another language

Month names are language-specific tokens. A parser configured for English will not necessarily recognise mars, mai, octubre or enero.

The rule is simple: match the language of the job posting. If you are applying in English, your months must be in English, even if the rest of your career happened in France or Latin America. If you are unsure which language the receiving system runs in, use the numeric format 03/2021 - 08/2024, which is language-neutral and sidesteps the question completely.

Seasonal and vague entries

Convert every one of them:

• Summer 2024 becomes Jun 2024 - Aug 2024
• Winter 2022 is ambiguous across hemispheres and calendar years - write the actual months
• Q3 2023 becomes Jul 2023 - Sep 2023
• Early 2021 becomes a real month, even if you have to estimate it

An estimate to the nearest month is far better than a label the parser will discard.

Where the date sits

Dates get lost through placement more often than through formatting. Keep them in the normal flow of the body text, on the same line as the job title and employer or on the line immediately below.

Do not put dates in:

• a header or footer - many parsers strip these regions before reading
• a text box or floating shape - often invisible to text extraction
• a table cell, where reading order can scramble the association between role and date
• a narrow sidebar column, where the date ends up detached from the job it belongs to

The failure mode is subtle: the job title is read correctly, the date is read correctly, but the link between them is lost, so the role gets no duration at all.

A safe layout looks like this:

Senior Data Analyst | Northgate Retail | Mar 2021 - Aug 2024

Or with the date on its own line directly under the title. Both keep the two elements adjacent in the extracted text.

Short contracts, freelance and concurrent roles

Short assignments still need real month boundaries. A three-month contract written as 2023 disappears into a rounding assumption.

For freelancing, create one entry covering the full trading period (Jan 2020 - Present, self-employed) and list clients as bullets underneath without their own date ranges. This gives the parser one continuous block instead of a dozen overlapping fragments that look like job hopping.

For two roles held at the same time, date both normally. Parsers that detect overlap generally count the calendar span once rather than doubling it, and the alternative - fudging the dates to avoid overlap - creates a false gap.

For a promotion inside the same company, give each title its own date range under a single employer heading, and keep that pattern identical for every promotion on the CV.

Education, certifications and expiry dates

Education can be dated with the graduation month and year alone: Jun 2019. A full range is fine too, provided it follows the same format as the rest of the CV. Ongoing study takes Sep 2024 - Present (expected Jun 2026).

Certifications need the issue date, and the expiry date when one exists: AWS Solutions Architect - Associate, issued Feb 2024, expires Feb 2027. Some ATS setups check whether a required certification is still valid on the date of the application, so an undated certificate is treated as unverified. Never write Certified 2022 and leave it there.

Before and after

• 2021 - 2023 becomes 02/2021 - 11/2023
• 03/04/2024 - 12/09/2025 becomes 03/2024 - 09/2025
• Summer 2024 becomes Jun 2024 - Aug 2024
• Mar 2023 - becomes Mar 2023 - Present
• Jan 2021 to Now becomes Jan 2021 - Present
• sept. 2019 - juin 2021 on an English application becomes Sep 2019 - Jun 2021
• Certified 2022 becomes Issued Mar 2022, expires Mar 2025
• 1/19 - 6/21 becomes 01/2019 - 06/2021

Quick checklist

1. Every entry has a month and a year, never a year alone
2. No day numbers anywhere
3. One format across the entire document, work history and education included
4. Four-digit years, two-digit numeric months
5. Present for ongoing roles, never a trailing dash
6. Plain hyphen with spaces as the separator
7. Month names in the language of the application, or numeric to stay neutral
8. No seasons, quarters or approximations
9. Dates in the body text, never in headers, footers, text boxes, tables or sidebars
10. Certifications carry an issue date and an expiry date when applicable

Ten minutes of cleanup here changes the number the ATS attaches to your profile. That number is what the recruiter filters on before anyone reads a word you wrote.