Your Résumé in Plain Text: Own It, Version It, Never Get Locked Out

Write your résumé as one plain-markdown file, keep it under version control, and export to PDF on demand. That single file is yours outright — it opens in any editor, converts to PDF, HTML, or DOCX, survives any app shutting down, and never gets paywalled behind a builder's export button. The format is the method.

The case for plain text is not aesthetic. It is about who controls the document. A résumé is the one file most people most fear losing access to, and the SaaS résumé builder is built to keep that access on its side of the wall — your data on its server, your export behind its pricing page. A markdown file on your own device flips that: the source is yours, readable by you forever, with no account standing between you and your own work history.

This is a how-to, not a manifesto. It explains the one defensible method, walks the steps to set it up, and lists the mistakes that break it. Along the way it settles a myth that drives a lot of bad résumé advice — the claim that "75% of résumés are auto-rejected by an ATS before a human sees them" — because the truth behind it is the practical reason plain text wins.

The method, in one sentence

Keep your résumé as a single plain-markdown file, track it in version control, and render it to a PDF when you apply. Everything else — the styling, the export, the per-role variations — is downstream of that one decision. You write content in text; the tooling produces the document. The source never leaves your hands.

Software engineer Scott Berrevoets, who keeps his résumé this way, names the payoff plainly: "With everything in a git repo I can make changes as I like, undo them easily, and use all of git's features on my resume." ¹ The file is the asset. The renderer is replaceable.

The reason a résumé fits this approach so well is its shape. Berrevoets again: "the very consistent structure and simplicity of a resume makes it a perfect candidate to be written in markdown." ² Headings, dates, bullet points — markdown was made for exactly that.

Why plain text means you own it

You own a plain-text résumé because nothing sits between you and the file. There is no account to keep, no proprietary binary to escape, no server that can paywall your export. The document is text on your own device — you read it, edit it by hand, and convert it to any format, with or without the original tool.

This is not the case with most résumé builders. Their business model depends on holding your data and metering what you do with it. The honest version of the own-your-document idea even shows up in vendor copy: Resumey.Pro describes itself as "the only resume builder that treats your resume as a plain text file. Writable in Markdown, auto-formatted on import, and exportable to PDF with one click." ³ When a product markets itself on not trapping your file, it is conceding what the default is.

Open-source projects prove the approach is established, not fringe. The popular markdown-cv project, released under the MIT License, is simply "A curriculum vitae maintained in plain text and rendered to HTML and PDF using CSS." ⁴ You fork it, you own the file, and no company is in the loop. JSON Resume makes the same bet at the data layer: "JSON Resume is a standard created to empower developers," and "Every part of JSON Resume is open source on GitHub." ^{5 6} The pattern is years old and tool-agnostic.

Why version control changes the document

Version control turns a résumé from a single fragile file into a tracked history you can branch, diff, and roll back. Every edit is recorded. You can keep one résumé for engineering roles and another for academic ones from the same source, and you can undo any change without keeping six files named resume_final_v3_REAL.docx on your desktop.

The author of markdown-cv, Eli Papa, made exactly this move when he switched his CV to markdown: "Hosting on GitHub there also means I can maintain different versions of the same file, eg. one resume for tech jobs and another for academic purposes." ⁷ One source of truth, many tailored outputs — that is a branch, not a folder of copies.

There is a quieter benefit too: separation of concerns. Berrevoets notes that with markdown, "The format and the content are for the most part separate, making it easier to focus on one or the other." ⁸ You edit what your résumé says without fighting how it looks, then let the renderer apply the styling once. That split is hard to get in a drag-and-drop builder and free in plain text.

The five-minute version

The fastest path is four steps, and it produces a clean, professional PDF on the first run. You do not need a builder account, you do not need to learn version control yet, and you can do all of it from a single plain-text note you already keep on your own device.

1. Write the résumé as one markdown file. Use # for your name, ## for sections, and - for bullets. Keep it single-column and text-only — no tables, no graphics.
2. Render it to PDF. Use any markdown-to-PDF converter or an open tool like markdownresume.app, which exports a "selectable-text PDF rendered by Puppeteer — ATS-parseable and print-ready" ⁹ with "no account required" ¹⁰.
3. Save the source somewhere you control. The .md file lives on your own device. That file, not the PDF, is the thing you keep.
4. Apply. Send the PDF; keep the markdown.

That is enough to own your résumé and produce a professional document. The next step, version control, is what makes it durable across years and roles.

The thirty-minute version

The fuller setup adds version history and per-role variants, and takes about half an hour once. Initialize a Git repository in the folder holding your resume.md, commit the first version, and from then on commit every meaningful edit with a short message ("added 2026 role," "tightened summary"). You now have a full, dated history of your own career document.

When you need a tailored résumé, branch instead of copying. A tech branch and an academic branch share the same base and diverge only where they must — exactly the workflow Eli Papa described above. Merge improvements back to the base so a good edit reaches every variant.

Finally, wire up a one-command render. A converter (markdownresume.app, a Pandoc setup, or the markdown-cv CSS pipeline) turns the current .md into a PDF on demand. Edit text, run one command, get a clean document. The source stays plain; the output stays disposable, because you can always regenerate it.

The myth that drives bad résumé advice

You have been told most résumés are auto-rejected by software before a human sees them. That number is fiction. The repeated "75% never reach a human" claim, as ResumeAdapter's ATS roundup puts it, is one where "That number is made up." ¹¹ It "traces to a startup that shut down in 2013 and never published a single study." ¹¹

The primary evidence points the other way. In a 2025 study, Enhancv interviewed 25 U.S.-based recruiters across tech, healthcare, finance, and other industries; 23 of them — 92% — said their systems do not auto-reject résumés for formatting, content, or design. ¹² LA-based recruiter Reggie Martin is blunt about the scare: "It's such a false narrative to me— that people don't understand— and it's taking advantage of them." ¹³

Recruiters describe the actual workflow as human. As Charkin Whitehead, a recruitment relationship manager at Allegis Global Solutions, told Enhancv: "The ATS systems that I've worked with don't automatically disposition people—we have to go in and do it." ¹⁴ Software files and searches your résumé. People decide.

The real failure mode is parsing — and plain text fixes it

The genuine risk is not rejection; it is parsing. When applicant-tracking software cannot read a résumé's structure, it mangles the data it hands the recruiter — and the usual culprits are visual. ResumeAdapter attributes a concrete share to layout: "tables, columns, and graphics cause 23% of failures." ¹⁵ Fancy formatting trips the machine, not the existence of the machine.

This is exactly where a plain-markdown source wins, and not by philosophy. Markdown renders to a single-column, text-first document by default — "single-column layout — the format ATS systems parse most reliably, even from PDF files." ⁹ There are no nested tables or text boxes to confuse a parser, because markdown does not produce them.

So owning a clean plain-text source is also the practical fix. The same property that makes the file portable and durable — it is structured text, nothing more — is the property that makes it parse cleanly. You do not choose between owning your document and getting it read correctly. The plain-text choice gives you both.

Why plain text outlasts the format wars

Plain text survives because it is fully documented and tool-independent — anyone can write software to read it, decades from now, without permission. A proprietary résumé-builder format depends on one company's software and one company's survival. A markdown file depends on nothing but the idea that text is text.

Digital-preservation standards make this concrete. The Library of Congress, ranking formats by how sustainably they can be preserved, defines its top factor this way: "Disclosure refers to the degree to which complete specifications and tools for validating technical integrity exist and are accessible to those creating and sustaining digital content." ¹⁶ Plain text and markdown sit at the high end of that scale; a closed binary that only one editor opens sits at the low end.

The consequence for a résumé is direct. The document you most need to still open in fifteen years should not depend on a startup still being in business in fifteen years — and plenty are not. A .md file you can read in any text editor is a hedge against every app's eventual shutdown. The file outlives the tool that made it.

Common mistakes

Most failures of the plain-text résumé come from quietly undoing the very things that make it work — usually by adding back the convenience a builder offered. The method is forgiving until one of these breaks it, and then it breaks the ownership or the parsing without warning. Avoid these five and the approach holds.

• Adding tables, columns, or graphics back in. They are the documented cause of parse failures ¹⁵. Keep the rendered output single-column and text-first; that is the whole advantage.
• Treating the PDF as the source. The .md file is the thing you own and version. The PDF is a disposable export — regenerate it, never hand-edit it.
• Skipping version control. Without it you lose the branch-per-role workflow and the full edit history, and you are back to a folder of near-duplicate files.
• Trusting a builder's "export" as ownership. An export you can only produce while logged in is access, not ownership. Keep the plain source on your own device.
• Over-styling the markdown. Custom HTML and exotic layout inside the file recreate the lock-in and parse risks you left behind. Let the renderer handle appearance; keep the source plain.

How this works with your own notes

The method needs exactly one thing from your tools: plain-markdown files you control. A résumé written as a plain-text note on your own device — readable by you, editable by hand, convertible to PDF whenever you apply — is the own-your-document idea applied to the highest-stakes file most people keep. No special mode, no format to escape.

That is the quiet fit for an own-your-data note app. Your résumé stays a local file you keep, version, and render on your terms; the editor and your files stay yours, with end-to-end encrypted sharing built in when you want a second reader. The same plain-text habit serves your notes elsewhere — it is, after all, the format an AI reads cheapest too.

The neighborly note: the open-source projects above, markdown-cv, JSON Resume, and markdownresume.app, are all good ways to do this. The point was never which tool you pick. It is that the file is yours.

Frequently Asked Questions

These are the questions people actually type when they want a résumé they control end to end. The short answers live here; the full answers are the sections above. Each one points back to the source it rests on, so you can check the claim before you trust it.

How do I write a resume in markdown?

Write one .md file: # for your name, ## for each section, - for bullets, kept single-column and text-only. Render it to PDF with a converter or an open tool like markdownresume.app, which produces a "selectable-text PDF rendered by Puppeteer — ATS-parseable and print-ready" ⁹ with no account required.

Should I keep my resume in Git?

Yes, if you want history and per-role versions. Version control records every edit and lets you branch — "one resume for tech jobs and another for academic purposes" ⁷ — from a single source. As one engineer puts it, you can "make changes as I like, undo them easily, and use all of git's features" ¹ on the file.

Is the 75% ATS-rejection statistic real?

No. The claim that 75% of résumés never reach a human is, as ResumeAdapter documents, one where "That number is made up" ¹¹ — it traces to a company that shut down in 2013 and never published a study. In a 2025 study, 23 of 25 recruiters (92%) said their systems do not auto-reject on formatting ¹².

Do ATS systems reject resumes with tables and columns?

Not by auto-rejection, but layout does cause real damage at the parsing stage: "tables, columns, and graphics cause 23% of failures" ¹⁵. A single-column plain-text résumé is "the format ATS systems parse most reliably, even from PDF files" ⁹, which is why markdown output avoids the problem by default.

Why is plain text better than a resume builder for owning my document?

Because nothing sits between you and the file. A markdown résumé is text on your own device — no account, no server, no paywalled export. Digital-preservation standards favor fully documented formats; the Library of Congress defines its top sustainability factor as the public availability of "complete specifications and tools for validating technical integrity" ¹⁶.

Will a plain-text resume still open in ten years?

Yes — that is the point. A .md file opens in any text editor and depends on no company staying in business. A proprietary builder format depends on one vendor's software surviving. Plain text is the hedge against every app's eventual shutdown.

The résumé is the one document you cannot afford to lose access to — so keep it as a plain file you own, version every change, and let the PDF be the throwaway. The tool that renders it can disappear; the file is yours to keep.

mnmnote.com keeps your notes — résumé included — as plain markdown on your own device, yours to edit, version, and export on your terms.