# Beat the ATS: Résumé Formatting That Actually Parses _ATS parsing isn't magic and it isn't folklore. Here are the concrete formatting rules — single column, real text, standard headings — that decide whether software reads your résumé or garbles it._ Source: https://resume-get.com/blog/beat-the-ats-resume-formatting-that-actually-parses Published: 2026-09-25T19:39:23.289Z Category: ATS & Keywords --- Most résumé advice about "beating the ATS" is folklore. You'll read that a single typo gets you auto-rejected, that you need to hit an exact keyword density, that recruiters never see what the software flags. Some of that is exaggerated; some is flat wrong. What's actually true is narrower and more useful: an applicant tracking system reads your file, tries to pull structured data out of it, and stores the result. If the parser mangles your work history into nonsense, a recruiter searching their database for "project manager, 5 years" may never surface you — not because you were rejected, but because the data is garbled. The fix isn't tricks. It's formatting that a parser can read. Here's how to build a résumé that comes out the other side intact. ## Use a single column Parsers read in a flow — roughly top to bottom, left to right, the way you'd read a page of text. A single-column layout matches that flow, so your job titles, dates, and bullets come out in order. Two columns break this. When a parser hits a page with a narrow sidebar and a wide main area, it often reads straight across both columns, interleaving them. Your sidebar skill "Python" can land in the middle of a sentence about your last job. Text boxes are worse: many systems treat a text box as a separate object and either read it out of sequence or skip it entirely. The contact details or skills you tucked into a sidebar box can vanish. The same logic rules out tables for layout. A résumé that uses an invisible table to align dates against job titles looks clean to you and reads as a grid of cells to the parser — and cell-reading order is unpredictable. Put dates inline with the job title instead, on the same line or the line directly below. ## Keep the text real and selectable Open your finished résumé in a PDF viewer and try to select a line of text with your cursor. If you can highlight it and copy it, a parser can read it. If your cursor selects nothing — if the page behaves like a picture — the text is baked into an image, and most parsers get nothing usable from it. This trips people who design a résumé in Canva, Figma, or Photoshop and export a flattened graphic, or who paste a screenshot of a nicely formatted page. It looks identical on screen. To a parser it's a blank wall. The text has to be actual characters in the file, not pixels arranged to look like characters. A quieter version of this problem: icons and graphical bullets. A little phone glyph next to your number or an envelope next to your email is usually a font icon or image with no text behind it, so the parser sees a number with no label — or drops it. Write the words. "Phone:" and "Email:" cost you nothing and read cleanly. ## Use standard section headings A parser looks for landmarks to decide what each block of text is. The most reliable landmarks are the headings everyone uses: **Work Experience** (or **Experience**), **Education**, **Skills**, **Certifications**. When it sees "Work Experience," it knows the dated entries below are jobs. Clever headings defeat this. "Where I've Made an Impact" might be true, but the parser has no rule that maps it to employment history, so the section underneath may get filed as miscellaneous text — or not associated with your job titles at all. Save the personality for your bullet points. Label the sections plainly. ## Make your dates parser-safe Dates are how the system calculates your years of experience and orders your roles, so write them in a format parsers expect. **Jan 2022 – Present** works. So does **January 2022 – March 2024** or the numeric **01/2022 – 03/2024**. What causes trouble: seasons instead of months ("Fall 2022"), a bare year when the role was under a year, ambiguous ranges, and the en dash or em dash rendered as something exotic. Put a real month and year on both ends of each role, in the same format every time. Consistency matters as much as the format itself — a parser that's learned your pattern from the first job applies it to the rest. ## Choose a standard font Stick to fonts that have been around long enough to be universal: Arial, Calibri, Helvetica, Georgia, Times New Roman, Garamond. They embed reliably and map cleanly to characters when the text is extracted. Novelty and heavily stylized fonts can carry odd character mappings, so the extracted text comes out with substituted or missing letters — your name turns into near-gibberish. This is rare with mainstream fonts and common with downloaded display faces. A résumé is not the place to show off a typeface. ## Keep your name and contact out of the header and footer This one surprises people. If you put your name, phone, and email in the document's actual page header or footer — the repeating margin region, not just the top of the body — some parsers ignore that region entirely. They're built to skip headers and footers because those usually hold page numbers and boilerplate. Your contact information disappears with the boilerplate, and a recruiter who wants to call you can't find a number. Put your name and contact details in the normal body of the page, at the top, as ordinary text. It will look the same and actually get read. ## .docx vs PDF Both can work, and the honest answer is it depends on the system. A well-made PDF with selectable text is read accurately by most modern parsers and preserves your layout everywhere. Some older or stricter systems still parse .docx more reliably, which is why certain job portals specifically ask for Word. A practical rule: follow the posting. If it names a format, send that. If it doesn't, a clean PDF with real text is a safe default — but keep a .docx version ready, because a single-column .docx is about the most parser-friendly file you can submit. Whichever you send, the formatting rules above matter more than the extension. ## Two myths worth correcting You don't need to strip your résumé down to plain ugliness. Bold, italics, normal bullet points, and sensible section spacing are fine — parsers handle them. The things that break parsing are structural: columns, tables, text boxes, images, header/footer placement. Fix those and you can still have a résumé that looks good to a human. And never paste hidden keywords in white text to game the match. The idea is to cram the job's terms invisibly so the system scores you higher. It backfires. Parsers extract the text regardless of color, so the hidden block shows up in the data a recruiter reads — and a wall of out-of-context keywords reads as exactly what it is. If a term genuinely describes your work, write it into a bullet where it's true. If it doesn't, leaving it off is the honest call. ## See what the parser actually extracts You can guess at all of this, or you can look. The only way to know how your file parses is to run it through something that reads it the way an ATS would and shows you the output — which sections it found, where your dates landed, whether your contact details survived. ResumeGet's component-score checker does this: it flags whether each part of your résumé parses cleanly and points to what's breaking, so you can fix a dropped section or a misread date before you apply rather than wondering after silence. Building and checking are free. The point isn't a magic score — it's seeing your résumé through the parser's eyes, then formatting so the version a recruiter searches is the one you actually wrote.