How to Extract Text From a PDF Without Uploading It

Extracting text from a PDF fails in one specific way, and almost every tool handles it the same wrong way. You drop in a scan, the tool reports that it converted the file, and you get a zero-byte .txt. Nothing tells you that the document was a picture of text rather than text. You conclude the tool is broken, or that you did something wrong, and you try a different site that does the same thing.

That is the failure worth understanding, so this page is mostly about it: how to spot it in ten seconds, why it happens, and what the text you do get can and cannot preserve. The numbers below come from running the tool on real files, not from reading its own description.

What a PDF's "text layer" actually is

A PDF does not store paragraphs. It stores drawing instructions: put this glyph at this coordinate, in this font, at this size. A paragraph is something a reader perceives from the arrangement — the file has no object that says "paragraph", and no object that says "line".

Extracting text therefore means reading the glyphs back and reconstructing the spaces and line breaks from their positions. That is why two extractors can produce different output from the same file, and why "preserves the layout perfectly" is a claim about a tool's heuristics rather than about the document.

A scan has none of this. A scanned page is one large image — a photograph of paper — and there are no glyphs in the file to read, only pixels. No amount of parsing recovers characters from pixels; that is a different job called OCR, and it guesses.

Measured: what actually comes out of a real document

I ran a real 15-page two-column academic paper — Attention Is All You Need, 2,215,244 bytes — through the tool in Chrome. The row reported 15 pages · 6,120 words · 39 KB of text, and the whole extraction took 270 ms from the file landing in the page to the result line appearing. No long task over 50 ms was recorded while it ran, so the page never froze.

The downloaded file was 39,774 bytes. The abstract came out intact, broken across exactly the lines it is printed on:

The dominant sequence transduction models are based on complex recurrent or
convolutional neural networks that include an encoder and a decoder. The best
performing models also connect the encoder and decoder through an attention
mechanism.

Those line breaks are correct, and that is the first thing to understand about the output: a newline in the middle of a sentence is not a bug. The producer printed the sentence on four lines, so the file records four lines. If you paste the result into a document, your word processor will reflow it — that is what it is for.

The author block came out in order, one line per item: name, affiliation, email, repeated eight times. The reference list survived from page 10 into page 11 with the entries numbered [1], [2], [3] and each citation split across its printed lines. The page-number footer printed at the bottom of page 10 appears in the text as a bare 10 on its own line, because that is a real piece of text on the page.

The honest part: reading order

This is where a text extractor's copy usually overpromises, so here is the measured behaviour instead.

Because the file stores positions rather than paragraphs, the order the text comes out in is the order the producer wrote it into the content stream. For a single-column document exported from Word, Pages or LaTeX, that is the reading order, and it comes out right. For a two-column paper, it often is not: in this file the abstract began at character 601 and a heading from the right-hand column appeared at character 2,874, so the columns were woven together rather than read one after the other.

That is a property of the format, not a defect that a better parser would fix. A tool that promises "pixel-perfect layout" for a two-column PDF is promising something the file cannot give it. What you can rely on is: the words, the page boundaries, and the printed line breaks. What you cannot rely on is column order, table structure, or a heading being next to the paragraph it belongs to.

For a table, expect rows of text rather than cells. If the table is the point, the PDF to Image tool and a spreadsheet will get you further than any text extractor.

When the PDF has no text at all

I built the case that breaks most tools: a 13,002-byte PDF with two pages, the first a normal page with real text and the second a single image stretched to fill the page — a scan, in other words. The result line read:

2 pages · 3 words · 16 B of text · no text layer on page 2

That is the behaviour worth having. The document is not rejected, because page 1 genuinely had text; page 2 is named, so you know exactly which page needs OCR and which does not. A tool that silently skipped the page would have handed you a file that looked complete.

With a document that is entirely images the answer has to be different, because there is nothing to hand back. A 663-byte single-page scan produces no file at all, and this sentence instead:

This PDF has no text layer. Its only page is an image — it is a scan or a picture of a document, so there are no characters to extract. Run it through OCR first, or use PDF to Image to see the pages.

An empty .txt is worse than that message in every way: it is indistinguishable from a bug, it gives no next step, and if you are processing a folder of files it quietly poisons whatever is downstream.

Truncated and locked files

Two more failures are worth knowing about because they look like success.

A download that stopped halfway still contains a valid PDF header, and a lenient parser will open it and return the pages it can still read. I tested this with the first 55% of the paper — 1,218,384 bytes of 2,215,244 — and it is refused rather than half-extracted: "This PDF is incomplete: it ends before the end-of-file marker, so the download or the copy was cut short." Half a document with nothing to say the rest is missing is the worst possible output for anyone extracting quotes or feeding a pipeline.

A password-protected file is refused with its own sentence, because its text is encrypted until it is decrypted — no parser can read it in place. Remove the password in a reader first. An encrypted 2,242,954-byte copy of the same paper produced: "This PDF is password-protected, so its text cannot be read."

How to check the output before you trust it

Three checks catch almost every bad extraction, and they take a few seconds:

1. Compare the page count. The row says how many pages it read; your PDF reader says how many pages the document has. If those differ, stop.
2. Look at the word count. 6,120 words for a 15-page paper is about 400 words a page, which is what a dense two-column paper looks like. A 15-page report that yields 200 words is a scan with a text header.
3. Read the last page of the text. Truncation is invisible at the top and obvious at the end. If the final paragraph is cut mid-sentence and the PDF's last page ends properly, the file you extracted from was incomplete.

This is also the argument for the per-page output: one .txt per page in a ZIP means a missing page is a missing file, which you can see, instead of a silent gap in one long document.

What the competition does

Two claims, both fetched from the pages themselves on 2026-10-17 rather than remembered.

Adobe's converter, under its drop zone: "Your file will be securely handled by Adobe servers and deleted unless you sign in to save it." That is a document going to a third party, and a sign-in between you and the download. For a contract, a payslip or a medical letter, the upload is the part that matters.

One of the client-side converters that does handle scans says this about the rest of the field: "most free tools fail completely on scanned documents, leaving you with empty output." That is the industry default, stated by a competitor, and it is the failure this tool is built around.

The other half of the category is the same tool with a task limit: two documents a day, or a queue, or a paywall on the batch. None of that applies here, because nothing is uploaded and there is no server to meter.

The short version

A PDF contains glyphs and positions, not paragraphs, so the text you get back is the words in the order the file stores them with the line breaks the producer printed. That is enough to search, quote and paste a normal document, and it is not enough to preserve a two-column layout or a table. If the file is a scan there is no text layer at all — the tool tells you which pages, by number, instead of handing you an empty file — and the fix is OCR, not another converter.

And none of it requires uploading the document anywhere.