Extract Text from PDF Online for Free

PDF to Text: Extract the Text Layer from a PDF File

A PDF to text converter reads the words that are already stored inside a PDF and hands them back as plain text you can copy, search, paste into another document, or feed into a script. This tool does that work directly in your browser tab: drop a PDF, and a JavaScript library called pdfjs walks through the document page by page, reads the text-drawing instructions embedded in the file, and assembles them into a downloadable .txt file. Nothing about the file's contents is uploaded anywhere to make this happen — the extraction runs on your own device, in the same tab you're already looking at.

This same extraction logic is also available through the tool's metered API, for anyone who needs it from an automated pipeline or a backend job instead of a one-off browser visit. The API version runs the equivalent extraction on the server instead of in a browser tab, which means the file itself does travel over the network for that particular path — a distinction worth understanding before you pick which one to use, and one this article covers directly further down.

How to Pull Text Out of a PDF with This Tool

1. Drop or select the PDF file you want to read from. The browser tool loads pdfjs the first time you use it and keeps the file entirely on your device from that point on.
2. The tool opens the document and steps through it one page at a time, calling pdfjs's text-content routine on each page to pull out every text fragment the page actually contains.
3. Each page's fragments are joined into a single block of text, and the pages are stacked together with a "--- Page N ---" marker between them so you can still tell where one page ends and the next begins.
4. The result appears as a downloadable plain-text file — no formatting, no fonts, no layout, just the characters the document holds.
5. If you'd rather call this from code instead of a browser, the same capability exists as a metered API endpoint: upload the PDF file, optionally specify a single 1-based page number to extract just that page, and get back JSON containing the extracted text, the page count, and a character count.

Either path bounds the source document to 500 pages, so an enormous scanned archive or a book-length manuscript won't quietly hang the browser tab or the server request — it will instead tell you plainly that the document is too large rather than spinning indefinitely.

Why People Need to Get Text Out of a PDF

• Copying a passage without the paragraph breaking oddly. Selecting text directly in a PDF viewer often grabs stray line breaks or column artifacts; running the whole page through an extractor and copying from the resulting plain text avoids that mangled formatting.
• Feeding a document into a summarizer, translator, or search index. Most text-processing tools want plain text, not a PDF binary — extracting first lets you paste the result into whatever tool actually does the summarizing or translating.
• Pulling a clause or figure out of a long contract or report. Once the whole file is plain text, a simple find (Ctrl+F) across it is often faster than paging through the original document looking for one sentence.
• Building a lightweight text archive from a folder of PDFs. Some people keep years of statements, receipts, or reports as PDFs and periodically extract the text so the content is searchable without opening every file individually.
• Automating extraction as part of a larger pipeline. Developers building document-processing workflows can call the API endpoint directly rather than scripting a browser, feeding the returned text straight into whatever comes next — indexing, classification, or storage.

How Extraction Actually Works — and What It Can't Do

A PDF that was produced by a word processor, a "print to PDF" function, or a report generator typically stores its text as a sequence of drawing operators: "place this glyph at this coordinate," repeated for every character on the page. That's the text layer, and it's what pdfjs reads when this tool runs — it isn't reading pixels or guessing at letter shapes, it's reading the literal character data the PDF already contains. That's why extraction from a normal, digitally-created PDF is fast, exact, and requires no interpretation at all.

A scanned or photographed page saved as a PDF is a fundamentally different kind of file: it's a picture of a page, with no text layer behind it at all. Ask this tool to extract text from that kind of PDF and it will honestly report back little or nothing, because there is nothing in the file's structure to read — the words exist only as pixel patterns in an image, not as character data. To be direct about it: this tool does not perform optical character recognition (OCR), so it cannot look at a scanned page and recognize the letters in the picture the way a dedicated OCR product would. If your source documents are scans rather than digitally generated files, an extractor built specifically around OCR is the right category of tool, and this isn't it.

Source document type	What extraction returns
Word processor export, "print to PDF," most generated reports	Full, accurate text — every character the page displays
Mixed document (some pages text, some pages a scanned insert)	Text pages extract cleanly; scanned pages return little or nothing
Fully scanned or photographed pages (no underlying text layer)	Little to no text — there is no character data to read, only an image
Password-protected PDF	Fails with a clear error rather than silently returning blank text

One more nuance worth knowing: because extraction just concatenates whatever text fragments pdfjs finds in drawing order, a page laid out in multiple columns can sometimes interleave lines from different columns rather than reading top-to-bottom-then-next-column the way a human eye would. For a single-column report or letter this is rarely noticeable; for a two-column academic paper or a densely laid-out brochure, it's worth skimming the output rather than assuming the reading order is guaranteed to match the visual layout.

It's also common for a document to sit somewhere between the two extremes above rather than being cleanly "all text" or "all scan." A report that was authored digitally but has a signed cover sheet scanned in as the first page, or a contract that includes a photographed exhibit halfway through, will extract perfectly on its text-based pages and come back mostly blank on the image-based ones. Nothing about that is a bug in the extraction — it's an accurate reflection of what each individual page actually contains at the file-format level. If you're processing a batch of similar documents and a few come back unexpectedly short, checking whether those specific pages are scans rather than generated text is usually the first thing to look at.

Browser Extraction vs. the API Endpoint

Both paths use the same category of extraction — reading the PDF's stored text layer, not performing OCR — but they differ in where the work happens and what you get back:

	Browser tool (this page)	Metered API
Where the extraction runs	In your browser tab, via pdfjs	On the server, via a Node build of pdfjs
Does the file get uploaded?	No — it stays on your device	Yes — it's sent as part of the request
Output format	A downloadable .txt file	JSON with the text, page count, and character count
Single-page extraction	Not offered in the UI (extracts every page)	Optional — pass a 1-based page number
Best suited for	A one-off document you have open right now	Scripts, backend jobs, or repeated automated extraction

Does This Tool Upload or Store the PDF I Extract Text From?

Using the browser tool on this page, no — the file you drop is read directly by pdfjs running inside your own browser tab, and the extraction happens entirely on your device. There's no upload step, no server round trip, and nothing about your document's content is transmitted anywhere to produce the .txt file you download; the tab doesn't even need a network connection once the pdfjs library itself has loaded. If you instead call the metered API endpoint — the option built for scripts and automated pipelines rather than a single manual extraction — the PDF you send is necessarily uploaded to the server so it can run the equivalent extraction there, because that's what makes the API usable from outside a browser in the first place. That upload is the one meaningful tradeoff between the two paths, and it's worth choosing the browser tool whenever a manual, one-off extraction is all you need.

Why did my scanned document come back with almost no text?

Because a scanned or photographed page has no text layer to read — it's an image of a page, not character data. This tool reads a PDF's existing text layer; it does not perform OCR, so it can't recognize letters inside a picture of a page the way a dedicated OCR tool would.

Can I extract just one page instead of the whole document?

The browser tool on this page always extracts every page and separates them with a page marker in the output. If you need a single page in isolation, the metered API accepts an optional 1-based page parameter and returns only that page's text.

Is there a limit on how large a PDF I can extract from?

Yes — both the browser tool and the API bound the source document to 500 pages. A document within that limit extracts normally; one beyond it is rejected with a clear message rather than left to hang indefinitely.

Does the extracted text keep the original layout, like columns or tables?

No. The output is plain text with no formatting, fonts, or layout information — just the characters in the order the PDF's internal drawing instructions present them, joined by spaces and line breaks. Multi-column layouts can occasionally interleave lines from adjacent columns rather than reading strictly top-to-bottom.

What happens if I try to extract text from a password-protected PDF?

The tool reports a clear error rather than returning blank or garbled text, because a locked PDF's content can't be read without first supplying the correct password. Remove the password first with a password tool designed for that step, then extract the text from the unlocked file.

Does the extracted text keep paragraph breaks and spacing exactly as they appeared?

Roughly, but not with pixel-perfect precision. The extractor joins whatever text fragments pdfjs reports for a page, so ordinary paragraphs and line breaks generally carry through recognizably, but fine details like exact indentation, tab stops, or unusual letter-spacing aren't preserved — the output favors getting the actual words right over reproducing the visual layout down to the last space.

Will special characters, accented letters, or non-Latin scripts extract correctly?

Generally yes. Text extracted this way comes out as standard Unicode, so accented letters, symbols, and non-Latin scripts embedded as real text in the PDF extract the same as plain ASCII characters would. The one case that still fails is a document where those characters exist only as an image rather than encoded text — the same no-text-layer limitation described above applies regardless of which script or alphabet is involved.

Related Tools

If the PDF you're pulling text from also needs to become a set of page images, the PDF to JPG converter rasterizes each page instead of reading its text layer. Before you extract from a large multi-file batch, the PDF merge tool can combine several PDFs into one document first. If the file you're working with is locked, run it through the password protect and unlock tool to remove the password before extraction. And if the source PDF itself is bulkier than it needs to be, the PDF compress tool can shrink it down before you archive it alongside the extracted text.