README to PDF,
not a web page

Open the README on GitHub and click the Raw button, then copy everything, or download the file and drop it here. Copying from the rendered README page instead will paste the formatted HTML, which loses the Markdown structure — take the raw text.

The parts of a README that usually break in other converters are the ones this handles deliberately.

• Fenced code blocks keep their language highlighting, and long lines wrap rather than running off the page
• Tables keep their alignment, and a table spanning a page break repeats its header row
• Task lists render as real tick boxes rather than literal [ ] characters
• Every heading becomes a PDF bookmark, so a long README stays navigable in a reader's sidebar
• Anchor links between sections stay clickable inside the PDF

READMEs lean on two things that only work in context. Badge images are hosted remotely, so they are fetched at conversion time and need to be publicly reachable — a badge behind a private registry will not appear. Relative links such as ./docs/setup.md point at paths inside the repository, so in a PDF they have nothing to resolve against; replace them with absolute URLs first if readers need to follow them.

A README is written for a web page, so a couple of switches usually help before exporting. Turn on Title page to promote the project name onto its own page from the front matter or first heading, and Contents to insert a linked table of contents — both are in the style panel. Page numbers are on by default.

The single most common mistake is copying from the rendered README page, which pastes formatted HTML and loses the Markdown structure. Take the raw text instead — either through the Raw button, or straight from the command line.

# 1. From the GitHub UI: open the README, click "Raw", select all, copy.

# 2. From the command line, straight to a file:
curl -L -o README.md \
  https://raw.githubusercontent.com/OWNER/REPO/main/README.md

# Note "raw.githubusercontent.com", not "github.com" — the second
# returns the HTML page around the file rather than the file itself.

A README is written for a repository page, where the project name is in the breadcrumb and the reader already knows what they are looking at. On its own as a PDF it lands without that context. Switching on Title page puts the project name and any front-matter author on their own page, and Contents adds a linked table of contents, which together turn a scrolling web page into something that reads as a document. For an audit or a hand-off, widening the margins is worth doing too — it leaves room for the reader to write in.

A README with a dozen sections — Installation, Usage, API, Contributing, License — stays navigable without any setting: every heading becomes a PDF bookmark automatically, so a reader's sidebar mirrors the document's structure. What the Contents option adds is different and complementary: a visible, linked table of contents printed at the front of the document, which is worth turning on when the PDF will be read on paper or sent to someone who will not think to open a sidebar.

Several patterns common in READMEs do not survive translation into a standalone document, and are worth checking before converting:

• Links to other repository files such as CONTRIBUTING.md or LICENSE become dead relative links, for the same reason badges and relative images do
• A hand-written table of contents using GitHub-style anchor links will not jump anywhere in a PDF viewer the way it does on GitHub's own page
• Badges served from a private CI host will not load, since they are fetched over the public internet at conversion time
• Anything rendered by GitHub itself rather than written in the file — the file tree, the language bar, release widgets — is not part of the Markdown and never converts