Guide

Convert a resume to Markdown, and what it costs

Converting a resume to Markdown is common advice that nobody has measured. This page converts eight and scores both ends. It does something real, and it hides something, and the second half is the part no guide mentions.

The measurement

Eight resumes, converted and rescored

Each file is read, turned back into a document, written out as Markdown, then read again and scored a second time. Same parser, same scorer, both ends. The last column counts the bullet lines that survived the trip as bullet lines.

File	Before	After	Bullets kept
Word: contact details in a page header	80/98	95/98	2
Word: laid out with a table	69/98	95/98	1
Word: contact details in a text box	65/98	95/98	1
PDF: single column, text layer intact	95/98	95/98	3
PDF: two columns	43/98	95/98	0
OpenDocument: styled headings, single column	95/98	95/98	2
Rich text: bold text in place of real headings	60/98	95/98	2
Plain text: no formatting at all	95/98	95/98	3

Every file lands on 95/98. Not close to it, exactly it, including the one that started at 43/98 and the rich text file that started at 60/98. Read that column on its own and the conclusion is that converting a resume to Markdown repairs it. That conclusion is wrong, and the last column is why.

Why the scores converge

Markdown cannot carry a layout mistake, so it stops reporting one

Every deduction separating those files is about where something sits on a page: a header a parser discards, a table that interleaves two jobs, a text box it never opens, two columns read in the wrong order. Markdown has none of those things. A heading is a line starting with ##, and nothing else can be mistaken for one.

Some of that is a real fix. The Word file goes from 80/98 to 95/98 and its page header is genuinely gone: the name, email and phone are body text now, where every parser reads them.

The part that is hidden

A score of 95 on a resume that is now wrong

Conversion cannot recover what extraction already lost. The two column PDF is read in the wrong order, and converting that result writes the wrong order out neatly. It arrives with 0 bullets, against 3 from the same resume in one column. Here is what came out, unedited:

## Summary
San Francisco, CA

## Skills
Go

### Cut median checkout latency from 840ms to 210ms by replacing per-requ
*Backend Engineer, Bellweather Data · Jun 2018 – Feb 2021*

The summary section holds a city. The skills section holds one word of five. An achievement has become a job title, cut mid-sentence. Every heading is the right shape, which is all a scorer checks, so this file scores the same as the clean one. The bullet count is the only column that still tells them apart.

The answer

When to convert, and when not to

Convert when the file already parses cleanly and you want it in version control, in a text editor, or fed to something that reads plain text. It is an excellent storage format: diffable, tiny, and impossible to break with a stray text box. The five clean files in that table came through with their structure intact.

Do not convert as a repair. If the original scores badly for a layout reason, converting produces a file that scores well and reads wrong, and you will have no signal left telling you so. Fix the layout in the original, then convert if you still want to.

And do not send Markdown to an employer unless they ask. A .md file is unusual enough to be rejected at the upload step, and a recruiter opening it sees hashes and asterisks. It is the format to keep, not the format to send. The format comparison covers what to send instead. These numbers are recomputed on every test run, so a change to the scorer fails the build rather than quietly making this page wrong. Run the parser on your own file in the checker, read how the score works, or see which layout choices cost the points in the guide to why resumes fail.