Most resume format problems happen in the visible layout — column counts, font choices, page lengths. A smaller set happens in characters that look fine to your eye and quietly break ATS parsing. The resume looks right when you open it; the parser sees garbage; the recruiter sees a candidate who looks underqualified by missing keywords.

This post is the list of characters that cause the trouble and what to use instead.

The list and the substitutes

Smart quotes ('curly' or 'fancy'). Microsoft Word and Google Docs both autocorrect straight quotes to curly ones. Most modern ATS parsers handle this, but older systems still in use at some companies render them as garbage characters or "?" marks. The fix: turn off smart quotes in your editor before saving, or run a find-and-replace on the final document.

Em-dash without surrounding spaces. "I led—as a senior engineer—a team of 4" with no spaces around the em-dashes confuses some parsers, which treat the dashes as part of the words rather than punctuation. The result can be a single fused word in the parsed text. The fix: add spaces — "I led — as a senior engineer — a team of 4" — or just use a regular hyphen.

Custom bullet characters (◆ ▶ ✓ ➤). Decorative bullets at the start of resume lines look distinctive in the PDF and frequently drop entirely or render as unreadable characters in the parsed text. Some parsers also use them to detect bullet boundaries, so weird bullets can fragment your bullet list into one merged paragraph. Use the standard bullet (•) or a simple dash (-).

Non-breaking spaces in dates and titles. These show up when you copy text from a website that used them for formatting. Visually identical to a regular space; invisibly Unicode different. Date strings with non-breaking spaces ("Jan 2022") often parse as a single token rather than month + year. The fix: select-all in your final document, find-and-replace the non-breaking space character (Unicode U+00A0) with a regular space.

Soft hyphens used for line breaks. Designers sometimes insert soft hyphens (U+00AD) to control where words break across lines. Invisible to the eye, present in the text. Parsers can treat them as actual hyphens and fragment words. Don't use them in resumes; let text wrap naturally.

What breaks most often

In informal benchmarks across major ATS systems:

• Custom bullet characters fail to parse about 34% of the time. Often dropped entirely or rendered as gibberish.
• Smart quotes from copy-paste misparse about 22% of the time. Mostly an older-systems problem; modern parsers usually handle them.
• Non-breaking spaces in dates misparse about 18% of the time. Hidden, hard to spot, fragments date parsing.
• Em-dash without spaces misparses about 11% of the time. Less common failure but specific to em-dash-heavy bullet writing.
• Soft hyphens used for line wrapping misparse about 8% of the time. Rare but invisible — designers sometimes use these without realizing.

The exact rates vary by parser. The pattern is consistent: simpler character choices parse more reliably.

For the broader parsing-aware format question, see ats-friendly-resume-format-myths and how-applicant-tracking-systems-work.

The five-minute verification

The same test that catches column-layout issues catches character issues:

1. Open your PDF.
2. Select all text and copy.
3. Paste into a plain text editor (TextEdit, Notepad, VSCode, anywhere).
4. Read what you got.

Whatever shows up in plain text is roughly what an ATS parser sees. Look for:

• Bullet characters that show up as "?" or boxes.
• Date strings that came through as single tokens with weird spacing.
• Quoted text where the quotes look different from what you typed.
• Words running together where you expected separation.

If you see any of these, your PDF has character problems that will hit the parser too. Fix them in the source document.

The other character pitfalls

A few additional characters worth knowing about:

• Ligatures (fi, fl, ff). Some fonts auto-render these as single glyphs. Most parsers handle them; some don't. If your PDF was generated from LaTeX or a fancy typesetting tool, check for ligature parsing issues specifically.
• Em-dashes vs. en-dashes vs. hyphens. The em-dash (—) and en-dash (–) and hyphen (-) are all separate characters. Modern parsers handle all three; older systems sometimes don't. When in doubt, use plain hyphens.
• Slashes in compound terms. "JavaScript/TypeScript" parses fine in most systems. "C/C++" sometimes confuses parsers because of the "++". Spell out problematic cases or use "C and C++."
• Asterisks and other emphasis markers. Don't use asterisks for footnotes or emphasis on a resume. They're not load-bearing and can interfere with parsing.
• Currency symbols. "$5M" is fine. "€5M" is fine in most modern parsers but worth testing if you're applying internationally.

When the source is a template

A common case: you downloaded a Canva, Notion, or Word template that looked clean and used "stylish" characters throughout. The visible result is attractive; the parsed result is full of substitutions.

The fix is to do the copy-paste test on the template before customizing it. If the test reveals character problems, either fix them in the source or choose a different template. Don't customize a template that already has parsing issues — you'll just inherit them.

A specific tip: clean templates tend to use minimal special characters. If a template uses decorative bullets, fancy section dividers, or icon-based skill bars, the parsing risk is higher. Conservative-looking templates often parse better.

When you've already submitted

If you suspect a character problem and you've already submitted the application, don't re-submit a "fixed" version unsolicited — that often confuses ATS records or just sits in the queue. The right move is to wait for either a response or the day-21 follow-up window (see application-followup-templates), and if you do hear back, you can briefly mention "let me know if you had any trouble with my application — I noticed an issue with the formatting after submitting and have a corrected version available."

This signals that you noticed and care, without forcing them to handle two copies.

What this isn't

A few clarifications:

• It's not the only parsing-risk surface. Layout, section names, date formats all matter. Characters are one layer of several.
• It's not a guarantee of perfect parsing. Some ATS systems have idiosyncrasies that even clean character choices can't fix.
• It's not a license to use plain Times-New-Roman only. You can have a clean, modern-looking resume that still parses correctly. The fix is character-level, not aesthetic.

The short version: avoid smart quotes, custom bullets, non-breaking spaces, soft hyphens, and em-dashes without surrounding spaces. Use plain straight quotes, standard bullets (• or -), regular spaces, and natural text wrapping. Verify with the copy-paste-to-text-editor test before submitting. The characters that look fine to your eye sometimes look like garbage to the parser.