AI PDF Analysis: How It Works and How to Get the Most Out of It

The question that comes up most about document analysis: does it really read the whole file, or does it yank out random sentences like the summarizers of a decade ago? The answer depends on what happens between the upload and the result, and that can be explained concretely, without hand-waving about artificial intelligence. Below is the document's path from PDF to finished analysis: how much text actually reaches the model, what happens to a file that doesn't fit, how document search works in the chat, and why a contract takes a completely different route than a research paper.

What the PDF analyzer does

You upload a file, the service returns a structured breakdown: an overview, a section-by-section split, key points and figures. A chat about the document appears next to it. The thing that separates this from previous-generation tools: the model doesn't pull the first sentence of each paragraph or count word frequencies. It reads the text and works out how it's built, where one section ends and the next begins, which clause sits under which. That's why clause 3.2 ends up inside section 3 in the result rather than beside it.

Short how-to: summarize a PDF with AI

The whole document goes to the model at once

This is the part people don't expect, so here are the numbers. The model behind the analysis has a context window of roughly one million input tokens. The service uses about 786,000 of it, leaving headroom for the prompt scaffolding and for error in the length estimate. 786,000 tokens is on the order of half a million words. For scale: War and Peace is about 580,000 words. So almost any real document, an 80-page contract, a dissertation, an annual report, goes to the model in one piece, whole, unsliced. The model sees the entire text at once, which is why it can connect a conclusion on page 200 to a caveat on page 12. A call like that costs around eight cents, which isn't a number worth economizing on completeness for.

What happens to a document that doesn't fit

If the text really is longer than the budget, map-reduce kicks in. The document gets cut into chunks of roughly 250,000 tokens with a 1,500-token overlap, each is analyzed separately, then the results are merged into one analysis. The overlap exists so an idea split across a chunk boundary doesn't vanish from both halves. It's noticeably worse than a single pass: at the seams the model loses some connections, because it reads the second half of an argument without the first in front of it. So map-reduce runs only when there's no alternative, not as the default. In practice a handful of documents out of a hundred ever reach it.

Detail level doesn't change what you think it changes

Brief, medium, and detailed control the length of the answer, not the length of what gets read. The model receives the whole document either way. What changes is the output budget: roughly 16,000 tokens on brief, 32,000 on medium, around 60,000 on detailed. The practical difference: "brief" doesn't mean the model skimmed, it means it read everything and wrote tightly. The confusion is expensive. People pick detailed hoping the model will read more carefully, when it reads identically and only the verbosity changes.

A contract takes a different route

Normal analysis works by selecting what matters from a document. For a paper that's exactly right. For a contract it's a disaster. A penalty clause isn't part of "what matters" in the model's judgment when the rest of the document is about equipment supply, and that clause is the one that costs you money. So legal documents get a separate mode built the opposite way: not select what's important, extract everything. Every clause, every obligation, with no filtering by importance. Each extracted clause carries the verbatim text from the document, a plain-language restatement, a category (obligation, right, payment, termination, penalty, confidentiality, governing law, dispute resolution), and a severity marker.

The severity marker filters nothing

This one deserves its own note, because it looks like a filter and isn't. Every clause gets an attention level: high, medium, low. It affects only how the clause is displayed. It's never used to drop a clause. In exhaustive mode every clause reaches the result regardless of its marker. The logic is simple: if the model decided which clause of your contract you didn't need, that would be precisely the importance-filtering this whole route exists to escape.

How to turn on contract analysis

The analysis settings have a "This is a legal document" checkbox. Tick it for contracts, agreements, and NDAs: it switches on exhaustive mode, which works through the document clause by clause instead of selecting what matters. Without the checkbox, a contract goes through the normal route like any other document — the service doesn't try to guess from the text or filename whether something is legal. The checkbox is the only way to switch on exhaustive mode.

Contracts and legal mode come up often enough on their own that there's a full dedicated guide for them: how clauses get extracted, what the risk marker actually means, how long contracts get segmented.

The complete guide to AI contract analysis

Long contracts: 60,000-token segments

Exhaustive extraction is limited by output, not input. The model can read half a million words, but listing every clause runs out at roughly 65,000 tokens of response, after which the answer just stops. So the decision to segment is made by estimating output size: if the expected answer fits, the contract is done in one call. If not, it's cut into segments of about 60,000 tokens with a 2,000-token overlap. The overlap is larger than in ordinary map-reduce, and the reason is written in the code next to the constant: splitting a clause in half is unacceptable. In ordinary prose a sentence lost at a seam is an annoyance. In a contract it's a lost obligation.

Re-reading at long segments

If the model is listing a segment's clauses and hits the output ceiling halfway through, the service notices the cutoff, splits that segment in half, and re-reads each half from scratch. If a half still doesn't fit, it gets split again, up to three levels deep. That's slower and more expensive than accepting the first answer as-is, but the clause list stays complete: nothing gets silently dropped because of a model output ceiling.

If a segment fails anyway

Failures happen: the model returns garbage instead of structure, the network drops, whatever. Here too there's a choice between failing quietly and failing loudly. The service inserts a visible marker in the failed segment's place, flagged at high attention, saying in plain words that this chunk, pages such-and-such, couldn't be analyzed automatically and needs a manual look. The failed segment is visible in the result. It doesn't disappear as though nothing had been there.

Why clauses don't double up at the seams

The logical question after the last two sections: if segments overlap by 2,000 tokens, clauses in the overlap land in both. They do, which is why duplicates are dropped when the result is assembled: clauses are compared by title and by the start of their verbatim text, both normalized. An important subtlety, also written in the code: only near-exact repeats caused by the overlap get dropped. This isn't filtering for "unimportant," and two genuinely different clauses with similar wording both survive. The assembled result also gets scanned for cross-references: clauses that point at other clauses. That's exactly where contracts bury the knife, when a general section is overridden by an appendix.

Document chat: search by meaning

Right after a successful analysis, a search index gets built over the document, separately from the analysis itself. The text is cut into chunks of roughly 500 tokens with a small overlap, and each becomes a vector: a list of numbers encoding meaning rather than letters. When you ask a question in chat, it becomes a vector too, and the six chunks nearest to it in meaning go to the model. Hence the main practical consequence: a query about "termination" finds the clause about "discharge of obligations" even though not one word matched. The index lives for 24 hours and is deleted along with an unsaved analysis.

How document chat works

Against Ctrl+F and skimming

Where the analyzer wins outright is triage: deciding which of the twenty PDFs in your inbox deserve attention, or getting oriented in a long report before reading the sections that matter. Ctrl+F is fast and free, but it only finds words you already know to look for. It won't tell you a paper's central argument, and it won't find the liability clause if that clause is named something else. Where the analyzer loses: a document you have to rely on exactly. A contract gets read in full before signing, and the breakdown is a starting point rather than a replacement for reading.

Getting the best result by file format

Files exported from a text editor (Word, Google Docs, LaTeX) work best. Those files already carry markup, so structure comes out cleanly. For scans and photographed documents, the result depends on text recognition quality: a quick test before uploading is trying to select the text with your mouse. If it selects, the file is text based and gets the most precise breakdown. Complex tables with merged cells, schematics, and diagrams are read by their text content; to double check a specific figure from a table, it's easy to confirm it in the chat.

Explanation instead of a summary

A separate scenario people confuse with summarizing: the problem isn't the document's length, it's its density. Three pages of a medical report or a patent claim take longer to read than thirty pages of a report. There's nothing to shorten. It needs putting into human language. That's a different request to the model and a different result.

How to explain a PDF in plain language

Comparing several documents

Each analysis works through one document and keeps one chat scoped to it. To compare several reports, analyze each one separately, then set the finished breakdowns side by side. That way it stays easy to track which point came from which source.

How to get an accurate result

What actually matters. Upload a text PDF rather than a scan when you have the choice: this outweighs everything else on this list combined. For a contract, tick the legal-mode box yourself, especially if the document isn't in English. Don't reach for the detailed level hoping for more care, the model reads the same either way. If the analysis missed what you needed, don't rerun the whole thing, ask in the chat: semantic search will find the chunk that didn't make the summary.

Languages and translation

A document in one language and a breakdown needed in another is the normal case: an English paper, a Russian summary. Translation happens inside the same pass, you don't order it as a separate step. The chat also answers in the language of your question regardless of the document's language. Exhaustive mode for contracts doesn't depend on language at all: it's switched on only by the "This is a legal document" checkbox, not by keyword matching, so it works the same whether the contract is in English, Russian, or anything else.

What to know before you start

The breakdown reflects the document's contents as written: if the text contains an inaccuracy, it carries into the breakdown too, because the model restates the document rather than checking it against an outside source. For contracts, the breakdown speeds up reading and lays every clause out clearly, but the final legal judgment call, what a specific clause means combined with the rest, is a human's job.

Exporting the result

A finished breakdown exports to PDF, DOCX, and Markdown on the Pro plan. Markdown is convenient when the breakdown goes into notes or a wiki, DOCX when it gets edited by hand afterward.

What happens to your file

An unsaved analysis and its search index are deleted automatically after 24 hours. A saved one lives until you delete it. The document text goes to a model through a provider, because otherwise it couldn't answer from it, and that's how every service in this class works. The sane rule: don't upload documents under a real NDA anywhere, us included. A contract a counterparty sent you for routine review is a different order of risk.

Privacy policy

Plan limits

Guest, no account: one document a day, up to 5 MB, two chat questions, nothing saved. Free Study plan after registration: three documents a day, up to 15 MB, four questions, results saved. Pro: no cap on documents or questions, files up to 300 MB, export to PDF, DOCX, and Markdown. Megabytes translate badly into pages: a 300-page text PDF can weigh a couple of megabytes while a 10-page scan weighs twenty.

Which model is under the hood

Gemini 2.5 Flash Lite via OpenRouter. Not the most powerful model on the market, and that's deliberate. For the job of reading a document, understanding its structure, and returning a breakdown, the gap between a fast model and the heaviest one shows up in rare cases: contradictory structure, narrow jargon from several fields at once. For an ordinary contract or report that gap doesn't justify a fivefold difference in response time. What it does bring is the million-token context that makes the whole point possible: not cutting the document into pieces.

What to compare it against

Comparisons with other services live on their own page, along with pricing and what's included in each. Keeping that here makes no sense: this is a guide to how the breakdown works.

Cruxly: pricing and how it compares

Common mistakes

Uploading a scan and expecting text-PDF accuracy. Not ticking the legal box on a non-English contract and getting an ordinary summary instead of a clause-by-clause breakdown. Reading a confident tone as accuracy: the model's tone is always confident. Treating a contract breakdown as legal advice. Asking the chat things the summary already answered.

If one thing survives from all of this, make it the difference between the two routes. Normal analysis selects what matters from a document, and for a paper or a report that's exactly right. Contract analysis extracts everything, because there the definition of "what matters" belongs to you and not to the model. Everything else, re-reading segments that ran out of room, the overlaps, the markers where things failed, grows from one idea: a silently lost clause looks exactly like a clause that was never there. Take the document sitting unread right now and run it. On a contract, don't forget the checkbox.