Best Resume Fonts: Why the Typeface Barely Matters and Encoding Does

What a parser actually reads

When you export a resume to PDF, the file contains two loosely related things: instructions for drawing glyphs on a page, and a text layer describing what those glyphs mean. A parser only ever touches the second one. That text layer is not plain text. Characters are stored as codes that depend on the font's encoding, and getting from those codes back to readable Unicode requires a mapping. Where a ToUnicode CMap is present and correct, the extraction is exact. Where it is absent or wrong, the extractor is guessing — and with CID-keyed or subsetted fonts it usually guesses badly, producing either nonsense characters or nothing at all. Font subsetting is the common culprit. To keep files small, exporters embed only the glyphs a document actually uses, and they frequently renumber those glyphs into a private, non-standard character map. Without an accompanying ToUnicode table, "Marketing Manager" can extract as a string of meaningless codes even though it renders perfectly on screen. This is why the practical advice converges on boring fonts even though the reasoning usually given for it is wrong. Calibri, Arial, and Georgia are not "preferred by ATS software." They are fonts that Word, Google Docs, and Pages have well-trodden export paths for, so the PDFs they produce carry correct Unicode mappings essentially every time. A font you downloaded and installed last week has no such guarantee, and a font from a design tool with aggressive subsetting has a meaningfully worse record. The corollary matters too: a beautiful standard font in a badly exported file still fails. Font choice is a probability adjustment, not a guarantee. The test at the end of this page is what actually tells you.

The ligature trap, which is real and mostly unreported

Here is a specific failure you can check on your own resume in thirty seconds, and one that no font-ranking page mentions. Many fonts automatically combine certain letter pairs into a single decorative glyph — fi, fl, ffi, ffl. These are ligatures, and typographically they are an improvement. In a PDF they are a single character with its own code, and the Unicode codepoint for the "fi" ligature is U+FB01, not the letters f and i. If the export does not map that glyph back to the two plain characters, extraction produces one of three outcomes: the ligature survives as an exotic character your parser may not handle, it is dropped entirely, or it becomes a space. The last is the dangerous one, because it is invisible when you skim. Look at the words that appear on a resume constantly: Certified. Qualified. Office. Financial. Efficient. Profile. Benefits. Classified. Notified. Fifty. Specific. Proficient. Every one contains "fi" or "fl". When the mapping fails, a recruiter searching for "Certified Nursing Assistant" does not match your resume, because your text layer says "Certi ed Nursing Assistant". The page looks perfect. The search misses you. Nothing tells you it happened. This is rare with straightforward Word and Google Docs exports and considerably more common with design tools, LaTeX, InDesign-style workflows, and PDFs generated through PostScript. If you built your resume in Canva, Figma, Illustrator, or a LaTeX template, this is the first thing to check. The fix, when it happens, is not to pick a different typeface. It is to disable discretionary ligatures in the export settings, or to export from a different tool. Word and Google Docs do not apply standard ligatures to body text by default, which is another quiet reason the boring path works.

The fonts that are actually safe, and why

The list below is not ranked by recruiter preference, because no meaningful ranking exists. It is grouped by how reliably each font is available and exports with correct encoding. Two criteria decide the grouping. Availability — is the font installed on essentially every machine, so a Word file renders as intended rather than being substituted? And export reliability — does the standard toolchain produce a correct Unicode mapping for it? Within the safe groups, the choice is aesthetic and you should treat it that way. Pick one, use it for both your resume and your cover letter, and stop thinking about it. The difference between Calibri and Georgia will not decide an application; the difference between a legible resume and a cramped one might. One note on the "conditionally fine" group: those fonts are perfectly good typefaces that are simply not installed everywhere. In a PDF they are fine, because the font travels with the file. In a .docx they are a liability, because a recipient without the font gets an automatic substitution — different metrics, different line breaks, and a two-page resume that arrives as three.

31 examples across 4 groups

Sizes, spacing, and the shape of the page

Sizing is where font choices actually affect outcomes, because it decides whether a human finishes reading. Body text: 10 to 12 point. Below 10pt you are asking a tired recruiter to squint, and it reads as someone who could not edit. Above 12pt on a full-length resume looks padded. Eleven is a safe default for most of the safe fonts. Your name: 16 to 22 point. It is the anchor at the top of the page and can carry real size. Section headings: 12 to 14 point, distinguished by weight or small caps rather than by a wildly different size. Bold at 13pt does more for scannability than 18pt does. Line spacing: 1.0 to 1.15. Single spacing with a clear blank line between entries beats loose spacing throughout. If you are padding with line height to fill a page, the content is the problem. Margins: one inch, tightened to no less than about 0.7 inch if you genuinely need the room, and consistent on all four sides. Below that the page looks crowded and the reader feels it before they can name it. One size caveat that catches people: fonts of the same nominal size are not the same visual size. Garamond at 11pt is noticeably smaller than Verdana at 11pt, because x-height varies enormously between typefaces. If you switch fonts to fit a page, check the result rather than trusting the number — a switch to Garamond can buy you a quarter page, and a switch to Verdana can cost you one. Use one font family throughout, or at most two — one for headings, one for body. Three is where resumes start to look like ransom notes.

PDF or .docx, and the substitution problem

Font choice interacts with file format in a way that is worth understanding, because it is the one place where picking the wrong font has a guaranteed visible consequence. In a PDF, the font travels with the file. It is embedded, so what you exported is what the recipient sees, on any machine, regardless of what they have installed. This is why the "conditionally fine" group above is genuinely fine in PDF — nobody needs Roboto installed to read your Roboto resume. In a .docx, the font does not travel. Word renders with whatever is installed locally, and substitutes when it cannot find your choice. The substitute has different character widths, so your careful one-page layout reflows: lines break in new places, a section slides onto page two, and a date column stops aligning. You will never see this happen, because on your machine it looks correct. That gives a simple rule. Send a text-selectable PDF unless the application specifically asks for Word. If it does ask for Word, use a font from the two "safe anywhere" groups — those are installed on effectively every business machine, so substitution does not occur. One more thing that is not about fonts but gets blamed on them: if you print your resume, sign it, and scan it back, the file becomes an image. There is no text layer at all, no font, and nothing to extract. Some systems run OCR on it and some do not. Always send a digitally generated file.

Where fonts get blamed for formatting problems

A great deal of "my resume did not parse and I think it was the font" is actually layout. It is worth separating the two, because changing your typeface will not fix any of the following. Two-column layouts. A sidebar is read straight across by many parsers, joining your skills column to your work history line by line. This is the highest-impact parsing problem there is and it is entirely independent of font. The reverse chronological layout exists partly to avoid it. Contact details in the page header. Word and Google Docs headers are a separate text layer that parsers frequently skip. Your name in 18pt Calibri is still invisible if it lives up there. Tables and text boxes. Both are containers a parser has to flatten, and the flattening order is unpredictable. Dates right-aligned via a table are the classic case. Icons and rating graphics. A phone icon instead of the word "Phone," or five dots representing Excel proficiency, contain no text at all. This is sometimes mistaken for a font problem because icon sets are often delivered as fonts — and if you use an icon font for real content, the extraction genuinely will be garbage, because the underlying characters are arbitrary letters mapped to pictures. Decorative bullet glyphs. Custom arrows and symbols from a dingbat font may drop or merge lines together. Use your editor's standard bulleted-list tool. So before you spend an evening comparing Calibri to Lato, check the layout. The typeface is close to the least consequential decision on the page.

The two-minute test that settles it

You do not need a font-scoring tool, and the ones that give you a number are not measuring anything real. You need a plain-text editor. Open the exact PDF you are about to send. Select all, copy, and paste into Notepad, TextEdit in plain-text mode, or any empty text field. What you are looking at is very close to what a parser receives. Then check four things specifically: Can you select the text at all? If not, the file is an image and nothing will read it. Is any of it gibberish? Strings of unrelated symbols mean the encoding is broken — a missing or wrong ToUnicode mapping. Re-export from Word or Google Docs rather than from a design tool. Search the pasted text for "fi" words. Type "certi" into your text editor's find box and see whether it matches "Certified". Do the same for "office", "profile", "benefits". If the letters have vanished or turned into spaces, you have the ligature problem, and the fix is the export settings or a different export tool. Are the special characters intact? Em dashes, en dashes, curly quotes, and accented letters in names are the other common casualties. If "José" came through as "Jos" or "José", the encoding is wrong. If all four pass, your font is fine — genuinely fine, whichever one you picked. If any fail, you have found a specific, fixable problem, and you now know it is an export problem rather than a taste problem.