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

Who actually uses this

The document that lands on the upload screen ranges wildly: a 40-page research paper, a 300-page annual report, a course reading list, a product spec, a client deliverable that needs to become a two-paragraph briefing by end of day. The breakdown, the chat, and the plain-language explanation all work the same way regardless of which one it is, because the model reads structure and meaning rather than a document type. What changes is what you ask for afterward: a researcher wants the argument and the evidence behind it, an analyst wants the numbers and where they came from, a student wants the material broken into something a night before an exam can actually get through, a PM wants a spec turned into three bullet points someone can act on without opening the original file.

What "reading structure" actually means

A document with numbered sections, nested clauses, or an appendix that redefines a term used in section two isn't a wall of paragraphs to a reader who knows the format, and the model works the same way. A financial report's "Note 14" reference gets tied back to the note itself instead of treated as a floating citation. A spec's "see 3.2" pointer inside section 7 lands in the right place in the breakdown, not stripped out because it looked like noise. That's the actual difference between reading and pattern-matching on sentences: the second one treats every paragraph as equally disconnected from every other, and most real documents are the opposite of that on purpose.

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.

Pulling numbers out of a long report without losing where they came from

A 200-page annual report has revenue guidance in the executive summary, the actual quarterly breakdown in a table on page 60, and a footnote on page 140 that changes how one of those numbers should be read. Splitting a document like that into chunks for analysis is exactly how that footnote gets lost: chunk 6 doesn't know chunk 14 exists. Because the whole report goes to the model in one pass, a question in chat about the guidance number can pull in the table and the footnote together, not just whichever chunk happened to contain the word "revenue." The same logic applies to a research paper's methodology section and its results, or a contract's terms and the appendix that quietly redefines one of them.

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.

What 200+ pages actually looks like in practice

Two hundred pages doesn't sound like a threshold worth mentioning until you picture what hits it: a doctoral dissertation, a full compliance manual, a year of monthly reports bound into one file, a novel-length PDF someone exported from a scanner. All of that fits inside a single pass with room to spare, since the budget is closer to half a million words and a typical 200-page document runs somewhere around 60,000 to 100,000. Map-reduce, the fallback for documents that don't fit, exists for the rarer case: a multi-volume report or a full year of transcripts stitched into one file, somewhere in the range of a million words or more.

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. The checkbox is the only way to switch on exhaustive mode: without it, a contract goes through the normal route like any other document, because the service doesn't try to guess from the text or filename whether something is legal.

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

Getting more out of the chat than one question

The chat isn't limited to one question about one fact. Ask it to list every place a specific term or number shows up across the document, compare two sections against each other, or draft a short outline of one part for your own notes. Each answer draws on the same document-wide search, so a follow-up question doesn't need to restate context the way pasting text into a general chatbot would. The two, four, or unlimited question count per plan applies to a whole conversation about that document, not to how narrowly each question is scoped.

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. Concretely: Ctrl+F on "penalty" misses a clause that calls it a "liquidated damages provision" instead, and misses it precisely when it matters most. The breakdown reads the clause for what it does, not what it's labeled, and sorts it under the right category regardless of the wording the drafter picked. 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. A scan photographed at an angle or with a low-resolution phone camera recognizes worse than the same page run through a flatbed scanner or exported from an office printer's built-in scan-to-PDF, since text recognition quality depends entirely on image clarity going in, not on anything the analysis does afterward. When the mouse-select test comes back empty, that's the moment to look for a cleaner scan rather than expecting the breakdown to compensate for what a text layer would have provided outright.

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

Getting through a paper you don't have time to read closely

A dense methods section or a proof-heavy result doesn't need shortening. It needs restating in plain language, and that's a different job from summarizing. Ask the chat to walk through a specific section, a proof, or an unfamiliar term the way you'd ask a labmate who already read it. The answer stays grounded in that paper's own text and notation rather than the model's general knowledge of the field, so it explains what this paper claims and how it gets there, not a generic textbook version of the topic.

A semester's reading list before an exam

A course reader or a stack of assigned chapters compresses into the same kind of breakdown as any other document: an overview, the section structure, the points actually worth remembering. The chat does the real work here, since exam prep is mostly questions, not reading: ask it to explain a term you keep half-understanding, walk through an example from the text a different way, or pull every mention of a specific concept across a long chapter. Three breakdowns a day on the free Study plan is enough to get through a chapter a night without paying for anything.

Turning a report into something you can hand off

A client deliverable or a spec document usually needs to become something shorter for someone who isn't going to read the original: a briefing, three bullet points for a stand-up, a summary that goes in an email. The section-by-section breakdown already does most of that work, and asking the chat for a shorter version scoped to one section, one requirement, or one decision point saves rereading the source for the fifth time that week. For a deliverable that needs to go into a doc afterward, the finished breakdown exports straight to DOCX or Markdown instead of getting retyped from scratch.

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. A common version of this: three vendor proposals or four quarters of the same report, where the actual work is spotting what changed between them. Running each through its own analysis and reading the summaries side by side surfaces the difference faster than opening all four PDFs and hunting for the paragraph that moved.

One PDF, several documents stapled together

A contract with exhibits attached, a report bundled with its appendices, a set of forms merged into a single file before upload: none of that needs splitting first. The model reads the whole file as it's structured, section headers and all, and the breakdown reflects that structure rather than treating 80 pages of exhibit as an extension of the main text. If a question in chat is scoped to one part specifically, naming the exhibit or appendix gets a narrower answer than asking about the document in general.

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. An engineering spec in German that needs a breakdown in English, or a Spanish-language contract someone in an English-speaking office needs to understand quickly, both go through the same single pass: the model reads the source language and writes the breakdown in whichever language you asked for, without translating the document first and analyzing the translation second.

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 one fits depends on how often a document lands on your desk, not on how important any single one is. Testing the service on one file, a contract someone just sent over, a report due today, fits inside guest access with no commitment. A chapter or a document a day during a semester or a busy quarter is what Study is built for, and it's free permanently, not a trial with an end date. Pro earns its keep once documents stop being occasional: daily reports, a stack of contracts in a single week, anything where re-hitting a daily cap becomes the actual bottleneck instead of the work itself.

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.