In this guide
Resume advice often says to replace en dashes, curly quotes and bullets with plain ASCII before applying. We tested that. In 13 resume lines full of typographic characters, the characters themselves were rarely the problem. What decided whether text came back clean was the font: whether the PDF carried a map from its glyphs back to Unicode, and whether the font you chose was the font that was embedded.
The short version
- With the font's ToUnicode map in place, the en dash in a date range, en dash without spaces, em dash, fi, fl and ffi, curly apostrophe, curly double quotes, bullet character, arrow and accented letters came back exactly from every producer and reader pair.
- Without the map, all 13 lines came back garbled in every reader. “–” became “±” and “Software” became “6RIWZDUH”.
- Ligatures were harmless in the font that was asked for. When LibreOffice swapped in LinuxLibertineG, pdf.js returned “Certifieed fienancial officcer, <U+0004>orkfloo<U+0004> efficciency”.
- Non-breaking spaces and soft hyphens changed quietly. That usually helps a parser rather than hurting it.
How a PDF stores a dash
A PDF does not store the characters you typed. It stores glyph codes, references to shapes in an embedded font, and where to draw them. For text extraction, the PDF specification gives each font an optional ToUnicode map: a table from each glyph code to the Unicode characters it represents. Section 9.10 of the specification describes it as the way a reader recovers text.
When the map is present and correct, an en dash glyph maps back to U+2013 and a curly apostrophe to U+2019. When it is missing or wrong, a reader has to guess, and there is nothing in the glyph itself that says what character it is.
What we tested
We wrote 13 resume lines, each built around one character people worry about: en and em dashes, a non-breaking hyphen, a soft hyphen, the fi, fl and ffi letter pairs, curly apostrophes and quotes, a bullet, a non-breaking space, an arrow and accented names. We set them once in Arial, which has no ligatures, and once in Palatino, which does.
Each set became a PDF two ways: Chromium's print to PDF and LibreOffice Writer's export from DOCX. A third PDF was the Chromium file with its ToUnicode maps deleted. pdf.js, Poppler's pdftotext and MuPDF read every file back, and we read the DOCX's own XML.
Producers: chromium@153.0.8010.12 (through playwright@1.63.0) and LibreOffice 26.8.1.1. Readers: pdfjs-dist@6.3.289, pdftotext from poppler@26.10.0, and mupdf@1.28.5. These are three open-source text extractors, one of them the library ATSPrep's own X-ray uses. Employer systems license their own parsers, which are not public and may behave differently. The results show what these files give back to these readers, not how any particular employer screens.
| Produced by → read by | Exact | Changed |
|---|---|---|
| Chromium print to PDF → pdf.js | 9 | 4 |
| Chromium print to PDF → pdftotext | 12 | 1 |
| Chromium print to PDF → MuPDF | 12 | 1 |
| LibreOffice Writer PDF → pdf.js | 10 | 3 |
| LibreOffice Writer PDF → pdftotext | 11 | 2 |
| LibreOffice Writer PDF → MuPDF | 11 | 2 |
| Chromium PDF, ToUnicode removed → pdf.js | 0 | 13 |
| Chromium PDF, ToUnicode removed → pdftotext | 0 | 13 |
| Chromium PDF, ToUnicode removed → MuPDF | 0 | 13 |
| LibreOffice Writer DOCX → document XML | 13 | 0 |
Dashes, quotes and bullets survived
With the map in place, the en dash in a date range, en dash without spaces, em dash, fi, fl and ffi, curly apostrophe, curly double quotes, bullet character, arrow, accented letters lines came back character for character from both PDFs in all three readers. Replacing them with hyphens and straight quotes would not have changed what these readers saw.
That matches how the format is meant to work. Each of those characters has its own Unicode code point, and a font that maps its glyphs to them hands the same code point back.
Characters that changed quietly
Some characters did change, though not in ways a reader would notice. The non-breaking space came back as an ordinary space in 6 of 6 PDF reads. The soft hyphen, an invisible hint for where a word may break, was dropped in 4 of 6. pdf.js returned the non-breaking hyphen in “Co‑founder” from the Chromium file as a plain hyphen-minus.
pdf.js also turned an accent typed as a separate combining mark into the single precomposed letter. All of these make the text more like what a person would type into a search box, not less.
The DOCX kept every one of these characters as written. That is accurate, but it means a parser reading a DOCX sees a non-breaking space where a search might expect a normal one. Either way, these are not the characters that garble a resume.
Ligatures, and the font you did not choose
Ligatures join letter pairs such as fi into one glyph. In the Chromium PDF set in Palatino-Roman, all three readers returned “Certified financial officer, workflow efficiency” exactly. A ligature glyph can map to a single Unicode ligature character such as U+FB01 (fi), which Unicode lists as a compatibility character that normalizes to the two plain letters, and these readers returned the plain letters.
The LibreOffice PDF was different, and not because of the ligatures. The DOCX asked for Palatino, but LibreOffice embedded LinuxLibertineG in its place (and LiberationSans in place of Arial). With that substitute, pdf.js returned 5 of 13 lines changed. Letters were doubled and “w” became an invisible control character. MuPDF broke the words apart. pdftotext read the same file exactly.
The fault here is in how that substitute font's glyphs map back to text, not in the letters fi. The same words in the font that was asked for came back clean.
- 01pdftotext: Certified financial officer, workflow efficiency
- 02pdf.js: Certifieed fienancial officcer, <U+0004>orkfloo<U+0004> efficciency
- 03MuPDF: Certifie d financial offic er, workflo w effic iency
Without the map, everything breaks
Deleting the ToUnicode maps changed every one of the 13 lines, in both fonts, in all three readers. pdf.js and pdftotext fell back to the raw glyph codes. In this embedded subset each glyph code sits 29 below the character's own code, so every letter shifts by the same amount: “S” becomes “6”, the en dash becomes “±” and the space becomes the control character U+0003. MuPDF returned the replacement character U+FFFD for each glyph instead.
This is the pattern behind most reports of a resume coming out as random letters. The dash and the curly quote are not special here. They are garbled because everything is.
- 01Software Engineer, 2019 – 2023
- 026RIWZDUH<U+0003>(QJLQHHU<U+000F><U+0003><U+0015><U+0013><U+0014><U+001C><U+0003>±<U+0003><U+0015><U+0013><U+0015><U+0016>
- 03Women’s health, the team’s lead
- 04:RPHQ¶V<U+0003>KHDOWK<U+000F><U+0003>WKH<U+0003>WHDP¶V<U+0003>OHDG
- 05Won “Employee of the Year” twice
- 06:RQ<U+0003>³(PSOR\HH<U+0003>RI<U+0003>WKH<U+0003><HDU´<U+0003>WZLFH
How to check and fix it
These follow from the results above.
- Copy a paragraph out of your PDF and paste it into a plain text editor. If it pastes as your words, the text map is there. If it pastes as shifted letters or boxes, it is not, and no amount of replacing dashes will help.
- Export the PDF again from the program you wrote the resume in, with its standard PDF export, rather than printing a scan or flattening the file. Avoid tools that turn text into outlines or images.
- Check the font that was embedded, not the one you picked. If your PDF tool or a different computer substituted a font, export from a machine that has it, or choose a common font such as Arial.
- Keep en dashes, curly quotes and accented names if you like them. With a working map they came back exactly.
- Send DOCX where it is accepted. It kept all 13 lines exactly.
Common questions
Do en dashes and em dashes break ATS parsing?
Not on their own. In our test, en and em dashes came back exactly from every PDF reader whenever the font carried its Unicode map. When the map was missing, the dash garbled, along with every other character on the line.
Should I use straight quotes instead of curly quotes on a resume?
You do not need to. Curly quotes and apostrophes came back exactly from both PDF producers in all three readers we tested. What breaks them is a font without a text map, which breaks plain letters too.
Why does my resume text come out as random letters?
The PDF's font has no usable map from glyphs back to Unicode, so readers return the raw glyph codes. In our test that turned “Software” into “6RIWZDUH”. Export the PDF again with a standard PDF export and a common font, then copy and paste a line to check.
Why does fi or fl disappear or turn into a strange symbol in my resume?
Usually because the font that was embedded maps its ligature glyphs badly. In our test the same words read back cleanly in the font that was asked for, and garbled in a substitute font LibreOffice chose instead.
How do I remove encoded bullet characters that show as garbled symbols?
A bullet that garbles is a symptom of the font's text map, so fix the export rather than the character: export again with a common font and check by copying a line. If you would rather not depend on the font, use a plain hyphen or the standard bullet •, which came back exactly in our test.
See whether your PDF's characters come back. Free, in your browser.
Sources and further reading
- PDF 32000-1:2008, section 9.10: Extraction of text content, Adobe / ISO
- PDF.js, Mozilla
- Poppler (pdftotext), freedesktop.org
- MuPDF, Artifex
- Alphabetic Presentation Forms (FB00–FB4F), Unicode Consortium
- General Punctuation (2000–206F), Unicode Consortium
- LibreOffice, The Document Foundation
Put it into practice on a real resume.
Each example is a complete resume with role keywords and bullets that show proof. Open one in the Studio and make it yours, then download it. The first download needs no account.
