PDF to Text for LLM Input
Read a PDF's text in your own browser — line and paragraph breaks reconstructed from its positioning operators — with a token estimate and a count of every glyph it could not map.
Choose a PDF above. The settings you change are kept in this page's URL; the file is not, because it never leaves your browser.
The reason to extract PDF text before a model sees it, rather than sending the PDF, is that you get to look at what the model would have been given. A document that returns 300 characters from 40 pages is a scan, and no amount of prompt engineering will make it answer questions about its contents; a document whose columns have interleaved will produce answers that are confidently half from one column and half from the other. Both failures are invisible if the extraction happens inside somebody else's pipeline.
Why the glyph split matters
A PDF does not store text, it stores glyph codes and a font. When the font carries a ToUnicode map, those codes have a defined meaning and the extraction is exact. When it does not — common in subsetted fonts from LaTeX and from some design tools — the codes mean whatever the font says they mean, and the usual fallback is to assume the standard Western encoding. That fallback is right most of the time and wrong in a way that looks like text, which is the worst kind of wrong. The proportion is printed above rather than hidden.
Then chunk it, do not paste it
A 40-page PDF is tens of thousands of tokens, billed on every request that carries it and competing for attention with your actual question. The token estimate above is there to make that concrete before you build the pipeline around it.