PDF to Markdown OCR: When Markdown Is the Right Export
By Schema LawPublished Updated
PDF to Markdown OCR reads a scanned PDF and writes the result as Markdown: a plain text file in which a few ordinary characters mark headings, lists, bold and tables. Choose it over Word when the text is headed for a wiki, a notes app, a comparison tool or a script, and not for a formatted document.
Most lawyers have never been asked for a Markdown file, and many will never need one. It earns its place in a handful of specific jobs, which this post sets out, along with its close relative, the HTML export.
What is Markdown and why would a lawyer want it?
Markdown is a way of writing structure into plain text. A line that starts with # is a heading, a line that starts with a hyphen is a list item, and words wrapped in two asterisks are bold. Any text editor opens the file, and many tools turn it into a formatted page.
The GitHub Flavored Markdown specification describes Markdown as "a plain text format for writing structured documents, based on conventions for indicating formatting in email and usenet posts", developed by John Gruber and released in 2004. That history explains its look. A Markdown file reads like a carefully typed email.
A short example, from an invented lease:
# COMMERCIAL LEASE AGREEMENT
This Lease is entered into as of March 3, 2021, by and between
**HARLOW PROPERTIES LLC** ("Landlord") and **DUNMORE FREIGHT, INC.** ("Tenant").
## 3. Base Rent
| Lease year | Monthly rent |
| --- | --- |
| 1 | $18,450.00 |
| 2 | $19,003.50 |You can read that without any special program. That is the point.
Reasons a lawyer or paralegal might want it:
- It stays readable for decades. A plain text file needs no particular software or version.
- It keeps structure that plain text drops. You can still see which line was a heading and which block was a table.
- Many tools accept it. Wikis, knowledge bases, note-taking apps and document assembly systems often take Markdown directly.
- It compares cleanly. Two versions of a clause can be compared line by line, with no hidden formatting to confuse the result.
- It is small. A long contract is a few dozen kilobytes.
And one reason not to: nobody files, serves or signs a Markdown file. It is a working format.
How does OCR output become Markdown?
OCR output becomes Markdown when the software records what each piece of text is, as well as what it says. Once a line is known to be a heading and a block is known to be a table, writing the # or the pipe characters is simple bookkeeping.
The steps, in general terms:
- The page image is read. Characters are recognized and put in reading order.
- Blocks are classified. The software decides which runs of text are headings, paragraphs, list items and table cells, judging by size, weight, position and alignment.
- Each block is written with its marker. A heading gets one to six
#characters by level. A list item gets a hyphen or a number. A table gets a row of cells separated by pipes.
Step 2 is where mistakes happen. A bold defined term on its own line may be marked as a heading. A table without ruled lines may be written as a run of paragraphs. The Markdown file makes such mistakes easy to see, because the markers are visible characters and not hidden styles.
Schema Law reads every page into this kind of structure once, and each export is built from it. The Markdown export is the most direct view of that reading. It contains each page's Markdown, with a line of three hyphens between one page and the next. In most Markdown viewers that line shows as a horizontal rule, so page boundaries stay visible.
Markdown is an export format on every plan, the free one included, and the pricing page lists how many pages each plan covers.
One practical effect: when a Word export has a heading at the wrong level or a list that looks off, opening the Markdown export of the same document shows you how the page was read. It is a quick way to tell a recognition problem from a Word formatting problem.
Markdown versus HTML versus plain text exports
Plain text keeps the words. Markdown keeps the words plus visible markers for structure. HTML keeps the same structure in tags that a browser displays as a formatted page. Pick by what will open the file next: a search tool, an editor or a browser.
| Question | Plain text | Markdown | HTML |
|---|---|---|---|
| Readable in a basic text editor? | Yes | Yes, with a few symbols | Hard to read with all the tags |
| Headings marked? | No | Yes, with # | Yes, with heading tags |
| Tables kept as tables? | Rows with tabs between cells | Pipe tables | Table tags |
| Looks formatted when opened? | No | Only in a Markdown viewer | Yes, in any browser |
| Good for pasting into a brief? | Yes | Symbols need removing | Paste from the browser view |
| Good for line-by-line comparison? | Yes | Yes | Poor |
| Good for a wiki or knowledge base? | Loses structure | Often accepted directly | Often accepted, sometimes filtered |
Some rules of thumb:
- Quoting a passage in a brief or an email: plain text. No markers to strip out. The guide to extracting text from a scanned PDF covers that export.
- Storing a document where structure should survive: Markdown.
- Showing the document to people in a browser: HTML.
- Editing the document as a document: none of the three. Use Word.
A common mistake is to choose Markdown and then paste it into Word. The # characters and pipes come along as literal text and have to be deleted. If Word is the destination, export Word in the first place. You can export the same upload in several formats, so there is no need to convert one export into another.
Where Markdown exports fit in a legal workflow
Markdown exports fit the parts of legal work that happen in text tools: internal knowledge bases, clause libraries, matter notes, comparison and scripted processing. They do not fit anything that goes to a court, a client or the other side as a finished document.
Clause libraries and precedent banks
Firms that keep model clauses in a wiki or a knowledge base can add language from an executed, scanned agreement without retyping it. Markdown keeps the headings, so a long agreement can be split into one entry per article by cutting at each # line.
Matter notes
Many note-taking applications store notes as Markdown. A converted order or letter dropped into a matter notebook stays searchable, and it keeps its headings and lists.
Comparing two scanned versions
When all you hold are two signed scans of what should be the same agreement, export both as Markdown and run a text comparison. Differences show up line by line. Treat each difference as a question, not an answer, because a recognition slip in either file looks the same as a real change. Check every differing line against both page images.
Input for scripts and extraction
Text with visible structure is easier for a script to work with than a Word file. A heading marker tells the script where a section starts. For structured data proper, where each page and table is a labelled value, the JSON export is the better fit, as the post on scanned PDF to JSON explains.
A caution on where the file goes next
A Markdown file is as confidential as the scan it came from. It is also very easy to paste into a chat window. Before any client text goes into a general-purpose AI tool, read the post on whether it is safe to upload legal documents to ChatGPT and follow your firm's policy.
A worked example: a paralegal receives a 40-page signed services agreement as a scan and needs its indemnity and limitation clauses in the firm's clause library. She uploads the scan, checks the two clauses on screen against the page images, exports Markdown, cuts out the two sections by their headings, and pastes them into the knowledge base with the document name and page numbers. The Word file never needs to exist.
When you file those clauses, keep the indemnification wording under its own heading. Note a severability sentence or a force majeure sentence if it sits in the same article, because a later drafter will look for it beside that covenant. Leave the signature block out of the library entry.
Tables and headings in exported Markdown
Headings in exported Markdown are lines that begin with one to six # characters, and tables are rows of cells separated by pipes. Both survive well when the scan is clean and the layout is simple. Tables are the weaker of the two, because Markdown tables are deliberately basic.
Headings
The number of # characters is the heading level, as the GitHub Flavored Markdown specification puts it: one for the top level, up to six. Levels come from recognition, which judges by appearance. Expect the occasional article heading and sub-heading at the same level, and the occasional bold line marked as a heading when it was not one. The post on whether OCR keeps formatting goes through which structure survives and why.
Clause numbers are part of the heading text. "## 3. Base Rent" has the number typed in. Nothing renumbers if you delete a section.
Tables
A pipe table has a header row, a row of hyphens, then data rows. Tables are an extension to the original Markdown, defined in that specification, so most modern Markdown tools display them and a few older ones show the raw pipes.
The format has limits that matter for legal documents:
| Feature of the scanned table | What a pipe table can do |
|---|---|
| A cell spanning two columns or rows | No merged cells; the content lands in one cell and its neighbors are empty |
| Two header rows | Only one header row; the second becomes a data row |
| A paragraph or a list inside a cell | Each row is a single line of text, so the cell is flattened |
| Column alignment for figures | Not something to rely on |
| A table continued on the next page | Two separate tables, one on each side of the page separator |
| A cell with no content | An empty cell, which is fine |
For a rent schedule or a simple fee table, a pipe table is perfectly usable. For a wide ledger you intend to total, export Excel or CSV from the same upload instead. A pipe table with fifteen columns is technically valid and unreadable in a text editor.
To check a table quickly, count the pipes on the header line and on two data lines. If the counts differ, a cell was split or lost on that row. Then compare the first row, the last row and any totals with the scan.
Converting a scanned document to HTML for an intranet page
To put a scanned document on an intranet page, export HTML and publish it, or paste its body into your content system. The HTML export is a complete page that opens in any browser, with one section per source page, so readers can still cite by page.
The Schema Law HTML export has a simple, predictable shape:
- The page title is the document's name.
- Each source page is its own section, beginning with a small "Page 1", "Page 2" label.
- Headings are heading tags at the recognized level, paragraphs are paragraph tags, and lists are ordered or unordered lists.
- Tables are real tables, with the first row as the header.
- Bold text is kept.
- A short block of styling at the top sets a readable serif font, a comfortable column width, table borders and a rule between pages.
Nothing in the file loads from elsewhere. It contains no scripts, no web fonts and no images, so it opens the same way with or without a network connection.
Steps for an intranet page:
- Upload the scan and check the parsed pages against the original, paying most attention to tables and numbered clauses.
- Export HTML. Like Markdown, it is available on every plan.
- Open the file in a browser to see it as readers will.
- If your intranet accepts uploaded files, upload it as it is. If it uses an editor, open the file in the browser, select all, copy, and paste into the editor.
- Add a line at the top saying what the page is: a conversion of a scanned original, where the original is kept, and the date it was checked.
- Set the page's access to match the document.
Things that go wrong:
- The content system strips the styling. Many editors remove style blocks. The page then takes on your intranet's own look. Tables may lose their borders, which is usually fixable in the editor's table settings.
- Readers treat the page as the original. It is not. Signatures, seals, letterhead and stamps are not in the HTML. Keep the scan linked from the page.
- The page is visible too widely. A firm policy manual belongs on the intranet. A client's signed agreement almost never does. Decide who may see it before publishing, not after.
- Page labels are deleted as clutter. Those labels are what lets a reader cite the scan. Keep them.
HTML suits documents the whole firm consults often: standing orders, local practice directions, an office lease, an engagement letter template, a records retention schedule that only exists on paper. For those, a page people can search and link to beats a scan in a shared drive. The export formats listed on the homepage show the other files you can take from the same upload.