How to Fix Messy PDF Text, Remove Broken Formatting, and Prepare Documents for Portals

Copy a paragraph out of a PDF and paste it somewhere else, and it usually arrives wrecked: sentences chopped into short fragments, words split by stray hyphens, page numbers wedged into the middle of a thought, and gaps wide enough to drive a truck through. The text is not corrupt. It is doing exactly what the file told it to do. Once you understand why, fixing it stops being guesswork and becomes a short, repeatable checklist. This guide covers the mechanics of PDF text extraction, the specific line-break problems it causes, how to get clean text past document portals, and exactly what happens to your file when you run it through the tool on the home page. For a shorter, task-focused version of this same material, see the How It Works page.

How PDF Text Extraction Works

A PDF is a drawing, not a document

A PDF is a page-description format, not a document format. It does not store "a paragraph of forty-two words." It stores instructions that place runs of glyphs at specific coordinates on a canvas: this string at x=72, y=684, in this font, at this size. Everything a reader perceives as structure, including paragraphs, columns, lists, and headings, is an illusion produced by where the characters happen to sit. There is no underlying concept of a sentence, a paragraph boundary, or a heading level anywhere in the file. Word processors and page-layout tools that export to PDF flatten all of that structural information down to coordinates on purpose, because the format's entire job is to guarantee a page looks identical on every device and every printer.

That guarantee is also the source of every extraction headache. Because the file format was optimized for visual fidelity rather than semantic structure, any tool that wants to recover "the text" has to reverse-engineer structure that was never stored in the first place. It is closely related to why you can't reliably reflow a PDF onto a narrow phone screen the way you can an EPUB: an EPUB stores flowing text, a PDF stores a fixed drawing of text.

How software turns coordinates back into words

When software extracts text, it walks the list of positioned glyph runs on each page and turns them back into a string. The naive approach reads runs in the order they were written into the file, which is usually, but not always, close to reading order. A more careful approach, and the one this tool uses, groups glyph runs by their vertical position first, so that everything sitting on the same horizontal baseline is treated as one visual line, and only then sorts those groups top to bottom and left to right. That single change is what keeps two-column layouts, tables, and sidebars from interleaving into nonsense.

Every visual line becomes its own fragment in the raw output, because on the page every visual line genuinely was its own drawing instruction, frequently with its own hyphen, its own trailing space, and no signal at all about whether the sentence continues on the next line or ends there. The result reproduces the page's line wrapping rather than the author's sentence structure. Widen the window in your text editor afterward and nothing reflows, because the breaks are now hard characters rather than layout: a plain \n sitting where a rendering engine used to make a decision about word wrap.

Reconstructing the original prose means undoing three separate transformations in the right order: rejoining words that were split by a hyphen at a line break, merging lines that belong to the same sentence while leaving genuine paragraph and list boundaries alone, and discarding content, such as page numbers and running headers, that was never part of the body copy to begin with. Do them out of order and you get new bugs: merge before you rejoin hyphens, for instance, and a split word ends up with a hyphen buried mid-sentence instead of removed.

Simplified for illustration. The tool operates on real glyph coordinates from your file, not on text like this.

Common PDF Line-Break Problems

Almost every messy extraction is some combination of the same handful of problems. Knowing which one you're looking at makes it obvious which cleanup option to reach for.

Hard line breaks mid-sentence

The most common problem and the most damaging, because it destroys the sentence boundaries that every downstream tool, such as a search index, a language model, or a spell checker, relies on to make sense of the text. A sentence that visually wrapped across four lines on the page arrives as four separate fragments joined by newline characters instead of spaces. The fix is to merge a line into the one above it whenever that line lacks terminal punctuation such as a period, question mark, or closing quote, since the absence of punctuation is the clearest available signal that the thought continues. Headings, short list items, and table cells are excluded from merging by checking whether the preceding line is already short and title-like.

Hyphenated word splits

Justified typesetting inserts a hyphen whenever a word is too long to fit on the current line and has to continue on the next one. That hyphen is a real character, stored in the file exactly like any other glyph, so it survives extraction intact. "Infor-" and "mation" arrive as two fragments joined by a hyphen and a line break, which, if merged carelessly, becomes "infor-mation" instead of "information". Rejoining correctly requires a narrower rule than "any hyphen at a line end": only collapse the break when a letter sits immediately before the hyphen and a lowercase letter immediately follows on the next line, so that genuine hyphenated compounds like "state-of-the-art" or "well-known", which are legitimately supposed to keep their hyphen, are left untouched.

Running heads, footers, and folios

The chapter title printed at the top of every page and the page number printed at the bottom are, from the extractor's point of view, just more text at a particular coordinate. They get pulled out alongside the body and interrupt the prose every few hundred words, often mid-paragraph. Because a running head repeats almost verbatim across pages while ordinary body text does not, it can be detected statistically: normalize the digits out of the first and last couple of lines on every page, tally which normalized patterns recur across most of the document, and drop any line that matches one of those patterns. A one-off line that happens to say "Table 3" on a single page survives, because it never repeats; a header that says "Page 4" and "Page 5" on consecutive pages does not, because after normalizing the digit it repeats on nearly every page.

Phantom whitespace

Kerning adjustments, tab stops, and justified-text spacing are encoded in a PDF as positioning offsets rather than as actual space characters. A naive extractor that inserts a space whenever there's a gap between two glyph runs can turn a single tab stop into a run of a dozen literal spaces, or a table's column alignment into an unreadable wall of whitespace. Collapsing any run of two or more spaces down to one, without touching newlines, removes this without disturbing intentional line breaks.

Column interleaving

On a two-column page, common in academic papers, newsletters, and reports, an extractor that reads glyph runs in the order they were written into the file, rather than in visual reading order, can alternate between the left and right column line by line. The output reads as two unrelated sentences spliced together, switching topic every few words. Grouping runs by vertical position before sorting horizontally, as described above, prevents this: everything in the left column at a given height is read together before the extractor moves to what sits at the same height in the right column on the next pass.

Getting Clean Text Past ATS Portals and Into Research Tools

How applicant tracking systems actually read your file

Applicant tracking systems, grant portals, procurement systems, and university application platforms all do roughly the same thing with an uploaded PDF: they run text extraction, then apply pattern matching to the result. They are looking for dates, job titles, section headings, email addresses, degree names, and keywords. What they match against is not your carefully designed layout. It is the flat string that extraction produced. For a deeper look at this specific problem, see the blog post on ATS formatting.

That distinction explains most of the folklore around "ATS-friendly" documents. A resume laid out in two columns can extract as interleaved nonsense, so the parser sees a job title fused to an unrelated date. Contact details placed in a header or footer sometimes fall outside the main content stream entirely and vanish. Text inside a graphic is invisible, because it is a picture, not text. Icons substituted for the words "email" or "phone" leave the parser with a bare string and no label to attach it to. Unusual fonts with broken character maps extract as mojibake: the right shapes on screen, the wrong code points underneath.

The practical move is not to guess which layouts are safe. It is to look at what the parser sees. Run your own document through extraction, read the output as plain text, and check three things: is every section heading present and on its own line, do the dates sit next to the roles they belong to, and did your contact details survive? Anything that arrives garbled in the extracted text will arrive garbled in the portal. Fix it in the source document, export a fresh PDF, and check again.

A pre-upload checklist

Before you submit anything to a portal that has a file size cap or a page limit, work through the same sequence:

• Confirm the file has real text. If extraction returns nothing, you have a scan. Run optical character recognition first. No amount of cleanup can recover text that was never there.
• Read the extracted text end to end. This is the parser's view of your document. Treat anything confusing in it as a defect in the source file.
• Trim to the pages that were requested. Portals frequently cap uploads at a few megabytes or reject documents over a set page count. Extracting a page range produces a smaller file without re-exporting or degrading the original.
• Keep the page order the reviewer expects. Cover letter, then resume, then references, not whatever order the pages happened to be scanned in.
• Check the file name. Many systems display it verbatim to the reviewer, and a name like final_v7_REAL.pdf is not the first impression you want.

Cleaning text for research, notes, and language models

The same problems bite outside job applications. If you are quoting a paper, hard line breaks mean your quotation will not match the source when someone searches for it. If you are feeding documents into a note system, broken paragraphs destroy the sentence-level chunking that search and retrieval depend on. If you are passing text to a language model, hyphen splits fragment words into tokens the model has to reassemble, wasting context and degrading accuracy. Markdown output helps here specifically: preserving bullet lists as list items and separating paragraphs with blank lines gives downstream tools the structural signals that the PDF threw away. The blog post on AI text processing covers this in more depth.

One habit is worth adopting. After cleaning, skim the first and last few hundred words of the output. Extraction problems cluster at document boundaries: cover pages, title blocks, appendices, and footnote blocks are where layout gets unusual and where automated cleanup is most likely to guess wrong. Two minutes of reading catches nearly everything.

Data Privacy & Security

Where your file actually goes: nowhere

Resumes, contracts, medical records, and legal filings are among the most common documents people need to clean, and they are exactly the documents that should not be uploaded to an unknown server. Everything on this page runs locally: the PDF is parsed inside your browser tab by PDF.js, page extraction is performed by pdf-lib in the same tab, and the file is discarded the moment you close or reload the page. There is no upload step in the code at all: no network request carries your file anywhere, which you can confirm yourself by opening your browser's developer tools, watching the network panel, and loading a PDF. You will see the page's own scripts and fonts load once; you will not see your document leave the tab.

What we collect, and what we don't

We do not ask for a name, an email address, or an account to use this tool, and nothing about the document you process, including its contents, its file name, or its metadata, is transmitted to us or to anyone else. Ordinary web server logs, generated automatically by the hosting infrastructure that serves this page, may record an IP address, browser type, and requested page for security and reliability purposes, the same way almost every website on the internet does. That log entry exists whether or not you ever open a file; it has nothing to do with the tool itself. Full detail on cookies, advertising, and third-party scripts is on the privacy policy page.

Why this matters for sensitive documents

A server-side PDF tool necessarily receives a full copy of your file, if only for the seconds it takes to process it, and that copy typically passes through request logs, temporary storage, and sometimes a queue shared across other users' jobs before it is processed and, hopefully, deleted. Every one of those steps is a place a document could be retained longer than intended, exposed by a misconfiguration, or included in a breach. Running extraction and page-copying entirely in the browser removes that entire chain: there is no server-side copy to retain, log, misconfigure, or breach, because the file's only home for the duration of the operation is your device's own memory.

Frequently asked questions