A footnote reference implies a note at the bottom of the same page. Markdown does not promise that, and the export tested here did not deliver it: notes were collected into a single section at the end of the document. That is still useful for sources — as long as you plan for the jump.
What the converter does with footnotes
Markdown to PDF supports GitHub-flavored Markdown, and its product notes describe footnotes as part of that feature set. GitHub's own documentation is explicit about placement: the position of the definition in the Markdown does not control where the note is rendered, and the note appears at the bottom of the Markdown. A standalone converter has no page-bottom footnote machinery, so the practical result is a notes section at the end of the document.
That distinction matters before you write, not after. A note used for a source or an aside can live at the end. A note that contains the instruction the reader needs mid-task cannot.
A small fixture
# Field notes
The first claim has a source.[^1] A second claim needs support.[^2]
A repeated reference to the first source.[^1]
[^1]: First source: [example record](https://example.com/a). Checked 2026-10-24.
[^2]: Second source with a longer explanation that should wrap onto a second line if the column is narrow.
## Missing definition
This reference has no definition.[^3]
What the checks showed
The fixture was opened in the live preview and exported to PDF on 24 October 2026. The observations below come from that one desktop session; they are not a survey of every Markdown tool or PDF viewer.
- References became superscript numbers. The first and second notes appeared as 1 and 2. A repeated reference to the first note reused 1 rather than creating a third number.
- The notes were collected at the end. The preview produced a "Footnotes" section after the body, with each note numbered and a return arrow back to its reference.
- A missing definition stayed literal in the preview. The reference with no matching definition,
[^3], appeared as plain text rather than as a numbered note. - The PDF kept the notes at the end, not at the page bottom. In a two-page export, the note was on page 2 after the body text, while its reference was on page 1. It did not appear at the foot of page 1.
- The PDF retained internal links. The reference and the return arrow were link annotations with named destinations, so the pair can navigate within the document in a viewer that supports those links.
Decide what belongs in a note
- Use notes for provenance, not instructions. A citation, a dataset version or a definition of a term works at the end. "Set the page size to A4 before exporting" does not; the reader may meet it too late.
- Keep each note to one or two sentences. Endnotes are read out of context, after the page they support. A long note forces the reader to hold the argument in memory while jumping to the back.
- Do not use a note to hide a caveat. If the caveat changes whether the document can be used safely, put it in the body or in an alert near the relevant instruction.
- Let numbering do its job. Repeated references reuse the same number, so do not invent manual markers like "see note 1 again". The generated link already provides the return path.
- Name the section in the body when it matters. If the document has several appendices, refer to "Notes" explicitly so a reader knows where the numbered references lead.
- Check every reference has a definition. A typo in the label leaves literal bracket text in the middle of a sentence, which is easy to miss in a long document.
When page-bottom notes are required
If the format demands true footnotes at the foot of each page, a Markdown-to-PDF export is the wrong instrument. Footnotes at the page bottom require a typesetting system that lays out the page and the note together. In this workflow the notes are endnotes, and calling them footnotes in the document would set the wrong expectation. For a report with a strict citation format, either accept endnotes or produce the final PDF in a tool that supports page-bottom notes.
Check the notes in the exported PDF
- Read the last page. Confirm every note is present and in the same order as the references. A note defined in a table or a list may be easy to lose in the source.
- Follow one reference and its return arrow. If the links work, the reader can move between the body and the notes. If they do not, the note number is still readable but the navigation is gone.
- Check the first page for orphaned markers. A reference whose note landed pages later should still have a visible number and clear surrounding text.
- Look for literal bracket text. Any
[^…]left in the body means a definition is missing or mislabelled. - Confirm the notes are not treated as body content. A "Footnotes" heading near the end is expected; a note appearing in the middle of a paragraph is not.
Diagnose a note that did not work
- The marker stays as
[^1]in the PDF - There is no matching definition. Check the label exactly, including the number, and make sure the definition line begins with the same label and a colon.
- The note appears at the end of the document
- That is the expected behaviour here, not a rendering fault. Plan for endnotes; move essential instructions into the body.
- Two references show the same number
- The same label was used twice. That is useful for repeated citations, but use a new label when you need a distinct note.
- The return arrow is missing
- Check the note in the preview before exporting. If the arrow is present there but not in the PDF, try another viewer before editing the source.
- A note contains a long paragraph or a table
- Move it into the body or an appendix with a heading. Notes work best as short, self-contained statements.
Delivery checklist
- Notes are used for sources and asides, not for instructions the reader needs earlier.
- Every reference has a matching definition with the same label.
- Repeated citations reuse a label deliberately; distinct notes use new labels.
- The last page was read and the note order matches the references.
- One reference and one return arrow were followed in the PDF.
- No literal
[^…]text remains in the body. - The document does not call the section "footnotes" if the format requires page-bottom notes.
Sources and scope
Checked 24 October 2026. The workflow is editorial guidance. Browser and PDF observations come from one desktop session and one two-page export on that date; no cross-viewer or accessibility audit is claimed.
- GitHub Docs: Footnotes — bracket syntax and the statement that the definition's position does not control where the note is rendered; notes render at the bottom of the Markdown.
- Markdown to PDF: product notes — GitHub-flavored Markdown support, including footnotes, as described by the product.
- Markdown to PDF homepage — current feature list.