How to convert a markdown readme file to a pdf document
- Step 1Locate or export your README — Use the
README.mdfrom your repo root, or any Markdown file. On GitHub you can grab the raw file from the repo's Code tab (Raw button) and save it locally. - Step 2Open the Markdown to PDF tool and drop the file — Load the Markdown to PDF converter and drop the
.mdfile onto the dropzone (or click browse). Accepted extensions:.md,.markdown,.txt. Conversion happens locally in pdf-lib. - Step 3Let it auto-convert — There are no settings to pick — the tool has no options panel, so it converts automatically as soon as the file is added. Headings become larger bold lines; everything else is 10 pt body text.
- Step 4Trim lines wider than ~100 characters first if needed — Each source line is truncated at 100 characters with no word-wrap. If your README has long single-line URLs or unwrapped paragraphs, hard-wrap them in your editor before converting so nothing is cut off.
- Step 5Strip rich elements the renderer can't draw — Fenced code blocks, tables, and image tags don't render as boxes/grids/pictures — the raw Markdown text prints instead. For a README that is mostly code or screenshots, convert the page to HTML first and use HTML to PDF, which renders styled markup.
- Step 6Download and hand off — Download the result (named
<filename>.markdown-to-pdf.pdf), attach it to the proposal, or print it for the docs package. Nothing was uploaded.
What the README renderer actually does to each line
The converter parses your file line by line with pdf-lib. This is the full behaviour — there is no hidden GFM engine.
| Markdown in your README | What appears in the PDF | Notes |
|---|---|---|
# Project Name | Bold line at ~16 pt | Size is max(18 - level*2, 10): H1=16, H2=14, H3=12, H4 and deeper=10 pt |
## Installation | Bold line at ~14 pt | The leading # characters and the following space are removed |
Install with **npm** | Install with npm at 10 pt | ** and * markers are deleted; the word is NOT made bold |
| A line of normal prose | 10 pt Helvetica, left margin 50 pt | Truncated at 100 characters — no word wrap, the rest is cut |
` bash ``` fence + code | The literal text bash and each code line as plain 10 pt | No shaded box, no monospace font, no syntax highlighting |
| col | col | table row | The literal pipe characters as a plain line | Tables are not drawn as grids |
 | The literal  text | Images and badges are not fetched or embedded |
[docs](https://…) link | The literal [docs](https://…) text | Links are not clickable and are not resolved |
Limits, formats, and where this tool sits
Free-tier limits and the real input/output contract for the README use case.
| Property | Value | Detail |
|---|---|---|
| Accepted input | .md, .markdown, .txt | MIME text/markdown or text/plain; matched on extension or type |
| Output | Single PDF, US Letter (612×792 pt) | Page size is fixed — there is no A4 / Letter selector |
| Free file size | Up to 2 MB | A README is almost always far under this; Pro lifts the cap |
| Fonts | Helvetica + Helvetica-Bold | WinAnsi character set — no emoji, no CJK glyphs |
| Line width | ~100 characters per line | Hard truncation; wrap long lines in your editor first |
| Privacy | 100% client-side (pdf-lib) | Source README is never uploaded |
Cookbook
Concrete README snippets and exactly what the PDF shows. Use these to predict the output before you convert.
A clean, text-forward README converts faithfully
Headings, install steps, and prose are exactly what this renderer is good at. Emphasis markers are stripped, leaving clean text.
README.md: # Acme CLI ## Installation Run **npm install -g acme-cli** to get started. ## Usage Acme reads a config file and prints a report. PDF output (text): Acme CLI ← 16 pt bold Installation ← 14 pt bold Run npm install -g acme-cli to get started. ← 10 pt, ** removed Usage ← 14 pt bold Acme reads a config file and prints a report.
A fenced code block prints as literal text
There is no syntax highlighting or code box. The backticks and code lines render as plain 10 pt text, so a heavily code-driven README looks raw.
README.md: ## Quick start ```bash npm run build && npm start ``` PDF output (text): Quick start ← 14 pt bold ```bash ← literal, 10 pt npm run build && npm start ``` ← literal, 10 pt Want a real code box? Convert via HTML to PDF instead.
A long unwrapped line gets truncated at 100 chars
Each source line is cut at 100 characters with no wrapping. Hard-wrap before converting to keep the full text.
README.md (one very long line): Clone the repo from https://github.com/acme/very-long-org-name/very-long-repo-name and then run the bootstrap script located in scripts/setup. PDF output: Clone the repo from https://github.com/acme/very-long-org-name/very-long-repo-name and then ru ← cut here Fix: insert a line break in the source so each line is < 100 chars.
A GFM table degrades to pipe characters
Tables are not rendered as grids. If your README documents an options table, the PDF shows the raw Markdown.
README.md: ## Options | Flag | Default | | ---- | ------- | | --port | 3000 | PDF output (text): Options ← 14 pt bold | Flag | Default | ← literal | ---- | ------- | ← literal | --port | 3000 | ← literal For a real grid, render the README to HTML, then HTML to PDF.
Plain release notes as a .txt file
The tool accepts .txt, so a CHANGELOG-style plain file converts identically — headings only kick in on lines that start with #.
CHANGELOG.txt: # v2.1.0 Fixed crash on empty config. Added --verbose flag. # v2.0.0 Initial public release. PDF output: v2.1.0 ← 16 pt bold (# detected) Fixed crash on empty config. Added --verbose flag. v2.0.0 ← 16 pt bold
Edge cases and what actually happens
Fenced code blocks have no syntax highlighting
By designThe renderer treats code fences as ordinary text. The lines and the code inside print as plain 10 pt Helvetica with no monospace font, no shaded background, and no colour. For a developer README where code fidelity matters, render the Markdown to HTML and feed it to HTML to PDF.
Lines longer than 100 characters are cut
TruncatedEach input line is sliced to 100 characters and there is no word-wrap, so a long URL or an unwrapped paragraph loses its tail. Hard-wrap long lines in your editor before converting. This is the single most common surprise for READMEs with badge rows or long links.
Badges and screenshots don't appear
Not renderedImage syntax like  or <img src=...> is printed as literal text, not fetched or embedded. README badges and screenshots simply won't show. To deliver visuals, build an HTML page with the images inlined and use HTML to PDF, or place images via Image to PDF.
Relative links don't resolve
Not clickableA link like [Contributing](CONTRIBUTING.md) prints as the literal [Contributing](CONTRIBUTING.md) text — it is neither resolved nor clickable. Replace relative links with absolute URLs, or remove them, before converting if a reader will rely on them.
Emoji and non-Latin characters
May dropThe PDF uses Helvetica (WinAnsi encoding), which has no emoji and no CJK glyphs. A 🚀 in your title or a Japanese section heading can fail to draw or render incorrectly. Keep the README text in the Latin-1 range, or use HTML to PDF with a Unicode web font.
Page size is always US Letter
FixedOutput pages are 612×792 pt (US Letter). There is no A4 or custom-size option in this tool. If your docs standard requires A4, convert the printed PDF afterwards, or render via HTML where the page box can be set in CSS.
Bold and italic markers are removed, not styled
StrippedOnly # headings get a weight change (bold). Inline **bold** and *italic* markers are deleted so the word prints in regular weight. This keeps prose clean but means inline emphasis is lost — fine for most READMEs, worth knowing if emphasis carries meaning.
Very large README near the size cap
2 MB free limitFree conversions accept files up to 2 MB. A text README is rarely close, but a generated monolith (e.g. an API reference dumped into one file) could approach it. Split it, or upgrade to Pro to lift the limit. Page count for the output is determined automatically as lines flow down each Letter page.
No paste box — file only
Upload requiredThe tool reads a dropped or browsed file; there is no textarea to paste Markdown into. Save your README to a .md or .txt file first. If you only have text on the clipboard, paste it into a new file in your editor and save.
HTML embedded in the README
Literal textGitHub renders raw HTML in a README, but this tool does not. A <details> block or a <div align="center"> prints as its literal tags. For READMEs that mix HTML, the HTML-to-PDF path is the accurate choice.
Frequently asked questions
Will GitHub-Flavored Markdown (GFM) render correctly?
No — this is a deliberately simple line renderer, not a GFM engine. It styles # headings (bold, larger) and strips */** emphasis, but GFM tables, fenced code blocks with highlighting, task lists, and strikethrough are NOT drawn as rich elements; they print as their literal Markdown text. For full GFM fidelity, render the README to HTML and use the HTML to PDF tool.
Can I use a custom CSS theme for the PDF?
No. This tool has no options panel at all and accepts no CSS. The output uses a fixed style: Helvetica body at 10 pt, larger bold headings, 50 pt left margin, US Letter pages. If you need brand fonts, colours, or spacing, build a styled HTML page and convert it with HTML to PDF.
Will relative links in the README work in the PDF?
No. Links of any kind (relative or absolute) are printed as their literal Markdown text — [docs](./docs) appears verbatim and is not clickable. Replace links you care about with plain absolute URLs in the source, or remove them, before converting.
Will my code blocks keep their formatting?
Not as code blocks. The triple-backtick fences and the code inside print as ordinary 10 pt text with no monospace font, box, or colour. A README whose value is in its code samples will look raw — convert it via HTML to PDF instead, where a <pre><code> block renders properly.
What page size does it output?
US Letter, 612×792 points. There is no page-size selector and no A4 option in this tool. If you need A4, render via HTML where the page box is set in CSS, or re-size the resulting PDF in a dedicated tool.
Can I paste the README text instead of uploading a file?
No — the tool reads a dropped or browsed file only; there is no paste box. Save the README as a .md, .markdown, or .txt file and drop it in. Conversion then runs automatically.
Why was the end of a long line cut off?
Each source line is truncated at 100 characters and there is no word-wrap. Long single-line URLs or unwrapped paragraphs lose their tail. Hard-wrap the lines in your editor (most editors have a 'wrap to column' or 'reflow paragraph' command) before converting.
Is my README uploaded anywhere?
No. The conversion runs entirely in your browser using pdf-lib; the file is never sent to a server. The only thing recorded — and only when you are signed in — is an anonymous run counter for your dashboard, which you can opt out of.
Will emoji in the README show up?
Generally no. The PDF font is Helvetica with the WinAnsi character set, which has no emoji glyphs. An emoji in a heading or badge row may fail to render. Keep text in the Latin range, or use the HTML-to-PDF path with an emoji-capable web font.
How do I get a README PDF that looks like GitHub's rendering?
Run the README through a Markdown-to-HTML step (any static-site generator or marked/markdown-it in the browser), apply a GitHub-like stylesheet, then convert the HTML with HTML to PDF. That path keeps tables, code highlighting, and images. This tool is for a fast, plain, text-only PDF.
Can it convert several README files at once?
This tool handles a single file per run — drop one .md, get one PDF. For multiple READMEs, convert them one at a time, then combine the PDFs with PDF Merge into a single docs package.
What does the output file get named?
The download is named after your source file with a .markdown-to-pdf.pdf suffix — for example README.markdown-to-pdf.pdf. Rename it to whatever your handoff requires after downloading.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.