Chat with PDF: How to Talk to a Document and Get Answers From the Text

Forty-page contract, and you need the one clause about termination. Ctrl+F searches for a word that might not be in the document at all: the lawyer wrote "discharge of obligations," you searched for "termination," and you get zero hits. Document chat solves exactly that. You ask questions to your PDF directly, searching by meaning instead of an exact string, and get the answer back with the document's own wording. This guide covers how Cruxly's chat works under the hood, why it answers from your file rather than general knowledge, and how to phrase questions so you stop getting vague answers.

What PDF chat is for, when you already get a summary

Upload a PDF to Cruxly and it gets analyzed right away: key points, a breakdown by section, the important numbers. That's enough to understand what a document is about in two minutes instead of an hour. Then you hit the thing a summary doesn't cover. A summary answers "what is this document about." Chat answers "what does it say about this one specific thing." The difference shows up fast on a contract. The summary tells you it governs equipment supply, has a liability section, and an appendix with specs. Useful, but if what you need is how many days you have to return defective goods, the summary says nothing. That detail didn't make the key points, because for the document as a whole it isn't key. For you, right now, it's the only thing that matters. In chat you ask about returns and get the answer with the wording from the clause.

How the chat finds the right passage

The mechanics are worth explaining, because they determine what kind of answers to expect. Right after analysis, the document text gets cut into chunks of roughly 500 tokens, about 350 words, with a roughly 50-token overlap between neighbors. The overlap exists so an idea split across a chunk boundary doesn't get lost in both halves. Each chunk runs through an embedding model, text-embedding-3-small, and becomes a vector: a list of numbers encoding the meaning of the text rather than its letters. When you ask a question, your question becomes a vector too, and the service looks for the chunks whose vectors are closest to it by cosine similarity. The six nearest chunks go to the model verbatim. That's why asking about "termination" finds the clause about "discharge of obligations": those phrasings mean nearly the same thing, so their vectors are neighbors, even though not one word matches. Ctrl+F can't do that by construction. It compares characters.

Why six chunks lands right

Six is enough room for a question that touches two nearby sections at once, a clause and the definition it depends on, a number and the paragraph that explains it. It's also few enough that the answer stays anchored to what's actually relevant instead of getting diluted by chunks that only mention your search terms in passing. A one-line factual question and a broader "walk me through this section" question pull from the same six-chunk budget, which is part of why narrower questions consistently retrieve better than broad ones.

Document chat versus plain ChatGPT

The difference isn't the model. Both run a language model of a similar class. The difference is what reaches the model's input. Ask ChatGPT about your contract without attaching it, and it answers from what it broadly knows about contracts of that type. The answer sounds confident and plausible, and that's the danger: it describes a typical contract, not yours. If your return window is unusual, the model has no way to know, because it never saw your text. In Cruxly's chat the model gets six verbatim chunks of your file plus an instruction to ground its answer in them. If a chunk says "fourteen calendar days," the answer says fourteen calendar days. That's a structural guarantee the answer is built on your source, not on statistics about similar documents. There's a second problem pasting text into a general chatbot doesn't solve: a real contract or a 100-page report often doesn't fit in a paste box at all, and whatever does fit loses the parts that got cut. Cruxly's chat works from the same document-wide index the analysis already built, so an answer can pull from page 3 and page 80 at once without you deciding in advance which pages to paste.

Step by step: how to ask a PDF a question

ChatPDF alternative: what Cruxly does differently

Follow-up questions don't start from zero

A conversation isn't graded question by question in isolation. The model sees the last ten messages of the exchange alongside the six chunks retrieved for the current question, so asking "what about the second one" after a question about deadlines doesn't require restating which deadline you meant. That context window runs to roughly 20,000 characters, enough room for a real back-and-forth without every message re-fetching the whole document from scratch.

Why the chat refuses off-topic questions

Ask a chat about a research paper for a borscht recipe and it'll decline and steer you back to the paper. That's deliberate. The moment a model starts answering beyond the document, it switches to general knowledge, and you lose track of where your file ends and something the model read somewhere begins. The line between "this came from my document" and "the model knows this from somewhere" has to be hard, or grounded chat has no point. The tradeoff is straightforward: a question about an adjacent topic the document touches in passing sometimes gets refused when answering would've been fine, and that's a fair price for making sure the chat never answers confidently outside your document.

What "grounded" actually rules out

Grounding isn't just a technical detail, it's what keeps an answer honest. Ask a plain chatbot to compare your NDA's confidentiality period against "the industry standard" and it can answer confidently with a number that isn't in your document and isn't checked against anything real. Ask Cruxly's chat the same question and it can only work from what's actually written in the six chunks it retrieved: it either finds the confidentiality period in your document or says it isn't there. The narrower answer is also the one you can trust.

When the answer isn't in the document

Grounding cuts both ways: a question about something the document genuinely doesn't cover doesn't get a made-up answer, it gets told there's nothing on that topic in the file. That's a feature, not a gap in coverage. A general chatbot fills a gap like that with its own background knowledge, seamlessly enough that you might not notice the answer stopped coming from your document. Cruxly's chat can't do that by construction, since the six chunks it retrieved are all it has to work with.

Chat on YouTube videos

Chat isn't PDF only. If you analyzed a clip on Cruxly, there's a chat next to the video summary too: it's grounded in the finished analysis of the clip and answers questions like "explain the second point in more depth" or "what does the author suggest for beginners" well. When you need the speaker's exact words or a quote, that's what transcription is for: it returns the full verbatim text, word for word. A recorded lecture works the same way as any other clip: the chat answers "why does this step come before that one" or "explain the second example again" well, since those are comprehension questions the finished analysis already covers.

Complete guide to AI video transcription

How many questions you get

The message limit is counted per analysis, not per day. A guest without an account gets two questions per document. On the free Study plan, four. On Pro there's no limit. Only your messages count. The service's replies don't. It works this way because of cost: every question is a separate model call carrying six document chunks in context, and it costs money whether you asked something real or were poking at the tool. Two questions is enough for a guest to tell whether the chat answers from their file or produces mush, and not enough to work through a whole document. That's intentional.

Chat history lives for 24 hours

If you just uploaded a file and never saved the analysis, the whole conversation is stored for 24 hours and then deleted along with the document's search index. Come back two days later on the same link and the chat is gone. This isn't a bug or stinginess: temporary data sits in fast in-memory storage, and keeping it there forever is expensive. To keep a conversation, save the analysis, which is available starting on the free Study plan. Saved analyses and their chat history move to a permanent database and stay until you delete them. One practical note: if a document conversation turns out useful and you know you'll come back to it, save it right then instead of "later." People usually remember the 24 hours on day two.

Long documents and file size

File size depends on plan: 5 MB for guests, 15 MB on Study, 300 MB on Pro. Megabytes translate badly into pages, because a 300-page text PDF can weigh a couple of megabytes while a 10-page scan with images weighs twenty. Go by the actual file, not the page count. As for text length, the search index is built over at most four thousand chunks, which is a lot: on the order of a million words, past almost any real document. If you somehow bring something longer, the index covers the beginning and the tail won't be searchable. On contracts, papers, and textbooks, hitting that ceiling is effectively impossible. Put concretely: a doctoral dissertation, a full compliance manual, or a year of reports bound into one file, several hundred pages each, still lands well inside that budget, because retrieval only ever pulls six chunks into any single answer regardless of how long the source document is.

How to phrase a question that gets a precise answer

Search runs on the meaning of your question, so the more specific the question, the better the chunks it finds. "Tell me about the contract" is a bad question: the entire document matches it equally, and you'll get six more or less random chunks from the beginning. "What penalties apply for late delivery" is a good question, because it lands in a specific section. Simple rule that works: use the vocabulary of the subject area you're asking about, even if you don't know the document's exact wording. Ask about money in money words, about deadlines in deadline words. Second technique: when an answer comes back generic, don't rephrase the same question, narrow it. Instead of "tell me more," ask "which clause states this and what is the exact wording there." Third: split compound questions. Asking about deadlines and penalties at once forces the search to straddle two topics and it finds worse chunks for both than it would for either alone. Fourth technique: if you know roughly where in the document the answer lives, name it. "In the payment section, what's the late fee" retrieves differently than "what's the late fee" alone, because the section name itself becomes part of what the search matches against.

Asking for something other than a fact

Not every good question is "what does clause 4 say." The same chat drafts a short outline of one section for your own notes, rewrites a dense passage in plainer language, or lists every place a specific term shows up across the document. All three pull from the same document-wide search as a factual question, they just ask the model to do something with what it finds instead of just reporting it.

Finding a term's definition without hunting for a glossary

Many contracts and reports define specific terms once, in a glossary or an early section, and then use them without re-explaining. "How does this document define 'confidential information'" or "what does 'material adverse change' mean here" pulls the definition from wherever it's written, without you scrolling back to find the glossary section first.

Asking in a different language than the document

The chat answers in the language of your question regardless of what language the document is in. An English lease reviewed with questions asked in Spanish, or a Russian report queried in English, both work the same way: retrieval finds the relevant chunks by meaning, which doesn't depend on the two languages matching, and the answer comes back in whichever language you asked in.

Lawyers: finding the clause you need

The most obvious use case, and the most common one after students. A contract arrives for review, there's no time to read it end to end, and you need specific things: who carries the risk, what the deadlines are, how termination works. Questions that genuinely work here: "what are the grounds for unilateral termination," "who bears the risk of accidental loss of goods," "is there a liability cap," "what is the window for quality claims." Each lands in its own section and pulls the wording out. One caveat worth stating: this speeds up reading, it isn't legal advice. The chat finds a clause and paraphrases it. Understanding that this clause, combined with two others, means something bad for your client is a lawyer's job, and the AI doesn't do it. For a contract specifically, legal mode goes a step further than chat alone: it extracts every clause in the document, not just the ones a question happens to surface.

Complete guide to AI contract analysis

Analysts: comparing figures across sections

A hundred-page report, and you need to know whether the forecast in the market section squares with the numbers in the financial section. By hand that's flipping back and forth with a notepad. In chat it's one question: "compare the growth forecast in the market overview with planned revenue in the financial section, is there a discrepancy." Semantic search pulls chunks from both sections at once, because both are about growth and revenue, and the model sees them side by side in one context. This is probably where chat beats manual search by the widest margin: connecting two places in a document that sit far apart physically but cover the same thing. The same approach works the other way too: start from a number in the financial section and ask which assumption in the market section it depends on. Chat doesn't care which direction the question runs, only that both pieces show up in the same retrieval. Still check the figures against the original if you're carrying them into your own document.

Comparing a vendor's terms against what you actually need

A proposal or a statement of work buries the terms that matter, payment schedule, deliverable dates, what counts as a completed milestone, inside pages of boilerplate. "What are the payment milestones and what triggers each one" or "what happens if a deliverable is late" gets the specific clause instead of a summary of the whole document. For a decision that comes down to two or three terms, that's faster than reading the proposal twice looking for them.

Pulling a number from a statement or invoice

A bank statement, an expense report, or a vendor invoice buried in a longer PDF usually needs one number checked against what you expected, not a full read. "What was the total for line items tagged as travel" or "does this invoice match the quoted rate from the contract" pulls the specific figure instead of making you scan a table by eye. The chat quotes the number as written in the document, so a typo or an unusual figure in the source shows up exactly as it appears rather than getting smoothed over.

Reviewing a lease before signing

A rental agreement buries the terms that actually matter, deposit conditions, notice period, who pays for what repair, inside pages of standard clauses that don't change anything about your specific decision. "How much notice do I need to give to move out" or "am I responsible for appliance repairs" pulls the answer straight from the lease instead of making you compare it against what a friend's lease said.

Understanding what's covered in an insurance policy

A policy document is written to be technically complete, not easy to scan under pressure, and the moment you actually need to know what's covered is usually the worst time to start reading it end to end. "Does this policy cover water damage from a burst pipe" or "what's the deductible for this type of claim" retrieves the specific clause instead of the general marketing language on the first page.

Students: getting through a textbook before an exam

The chapter isn't landing, the exam is in two days, and there's nobody to ask. Chat works here like a patient person who read the chapter and will explain it as many times as you need. A sequence that works: start with "explain the main idea of this chapter in plain language," then on the parts that don't click, "explain why this follows from that," then "give me an example from the text." Separately useful: "ask me five questions about this chapter." Testing yourself beats rereading. Honest warning: the temptation to read the summary instead of the chapter is enormous, and an exam exposes that instantly. Chat is good when you're reading the chapter and get stuck, not when you skipped it.

Complete guide to AI PDF analysis

Researchers: working through a paper

A paper outside your field reads slowly, because half the time goes to terminology and to figuring out what the authors actually did. The questions that save the most: "what hypothesis was tested and by what method," "what was the sample and how was it recruited," "what limitations do the authors acknowledge themselves." That question is worth asking almost every time. The limitations section is written more honestly than the abstract, and it tells you quickly how much to trust the result. One more: ask "what specifically is new here compared to prior work," and the answer usually surfaces the paragraph from the introduction where the authors state it themselves.

Reading an offer or an employment contract before signing

A job offer or an employment contract is dense in a specific way: compensation structure, notice period, a non-compete clause buried in section nine. Questions that get straight answers here: "what's the notice period if I resign," "is there a non-compete, and how long does it last," "when does the signing bonus vest." Each pulls the exact clause instead of a paraphrase of the whole document. Reading it end to end still matters before signing anything. The chat just gets you to the three clauses that actually change your decision faster than scanning ten pages for them.

Journalists checking a claim against the source document

A press release, a court filing, a leaked report: the question isn't what the document says overall, it's whether one specific claim actually holds up. "Does this report actually say revenue grew 12 percent, or is that a rounding of a different number" pulls the exact sentence instead of trusting a paraphrase from a press summary. Grounded retrieval matters most here: the answer only exists if it's actually written in the source, and a chat that can't find it says so instead of guessing at what sounds plausible.

What happens to your file

The question people ask more than all the others combined, especially about contracts and financial reports. Short version: an unsaved analysis, its search index, and its chat history are deleted automatically after 24 hours. A saved one stays until you delete it. The document text does go to a model through a provider. That's structurally true of every service in this category, including the ones implying otherwise: for a model to answer from your document, your document has to reach the model's input. The sane rule: don't upload documents under a real NDA anywhere, including here. For a contract a counterparty already emailed you for review, the risk is a different order of magnitude.

Privacy policy

What you get free and without an account

A guest analyzes one document per day, up to 5 MB, and asks two questions about it, no account required. That's enough to test the service on your own document instead of a demo. Registering on the Study plan is free and raises the ceiling: three analyses a day, four questions each, files up to 15 MB, and most importantly the ability to save analyses so they don't vanish after 24 hours. Pro removes the limits on questions and analyses, raises files to 300 MB, and unlocks export. Export gets its own note below, because there's a catch.

Which plan fits comes down to how often a document needs more than a summary. Testing the chat once on a document that just landed in your inbox fits inside guest access. A chapter or a contract a few times a week is what Study covers, free permanently. Pro makes sense once chat turns into the default way you get through documents rather than an occasional shortcut.

Exporting the result

A finished document breakdown exports to PDF, DOCX, and Markdown on the Pro plan. Markdown suits notes and wikis, DOCX suits anything edited by hand afterward, PDF suits forwarding as-is.

The chat doesn't start from a blank slate

A difference you don't notice immediately. By the time you ask your first question, the document is already analyzed: there's a summary, a section breakdown, key points. The chat model sees that analysis alongside the source chunks. Which is why a question like "does this even matter?" makes sense here: the model has a picture of the whole document to weigh a specific chunk against. A tool where chat is the only feature starts from zero on every question and has no such picture. Side benefit: often the answer is already in the summary and you don't need the chat at all, which takes about ten seconds to notice.

How the full PDF analysis works

Chat and video summaries together

If you work with YouTube, it helps to see the whole set. A summary gives you the gist of a clip in two minutes. Transcription gives you the verbatim text when exact words matter. Chat lets you clarify what you didn't understand, grounded in the analysis of the clip. Three tools for three jobs: reach for the summary for a quick gist, transcription for an exact quote, and chat to clarify and dig into details.

Complete guide to AI YouTube summaries

Comparing two documents by chatting with each

Chat is scoped to one document at a time, one analysis, one conversation. To compare a vendor's old contract against a new draft, or last year's report against this year's, analyze each one and ask the same question in both chats: "what's the payment schedule" against document A, then the same question against document B. Reading the two answers side by side finds the difference faster than holding both documents open and cross-checking by eye.

Re-running a question after the document changes

A revised contract or an updated report is a new document to the service, not an edit to the old one. Uploading the new version starts a fresh analysis and a fresh chat, so a question that got one answer on draft one can get a different answer on draft two, and re-asking it is the way to check what actually changed between versions.

Cross-checking an answer against itself

A fast way to sanity-check a chat answer that matters: ask the same question a second time, phrased differently, and see whether the specific wording matches. "What's the termination notice period" and "how many days of notice does either party need to give to end this" should retrieve the same clause and the same number. If the two answers disagree, that's the signal to go read the clause directly instead of trusting either paraphrase.

What a good answer actually looks like

A strong answer names something specific: a clause, a number, a page, a phrase close to the document's own wording. A weak one stays general, restates the question back at you, or reaches for language that sounds like a summary rather than a quote. The second kind is worth treating as a prompt to narrow the question rather than as the final word, since it's often a sign the six retrieved chunks didn't actually contain what you needed.

Common mistakes

The most common ones. First: asking the chat things the summary already answered, instead of reading the summary first. Burns messages from your limit and wastes time. Second: reading a confident tone as a sign of accuracy. The tone is always confident. That's a property of the model, not evidence the right chunk was found. Third: not saving an analysis and discovering the conversation is gone the next day. Fourth: uploading a bad scan and being surprised by empty answers. If the text in a PDF doesn't highlight with your mouse, it's an image, and OCR errors feed straight into retrieval. Fifth: asking the same thing three ways in a row instead of narrowing the question.

When chat saves the most time

A practical rule of thumb. Chat wins when the document is long, you need a specific part of it, and you roughly know what you're looking for but not what it's called in the text. The termination versus discharge-of-obligations case. A second strong scenario: connecting two distant places in a document that sit far apart physically but cover the same thing. That's exactly where manual search falls furthest behind.

The thing worth taking from this guide: document chat is semantic search with an explanation layer on top, not an omniscient reader. It's strong exactly where semantic search is strong, and weak where you need counting, completeness, or verbatim text. Understanding that boundary saves more time than any list of ready-made prompts, because you stop asking it questions it cannot answer by construction. Take the document sitting unread on your desktop right now and ask it the one question you opened it for. Two guest questions is enough to find out whether this is your tool.