Sourced from Google's own Gemini Notebook plan-limits documentation and source documentation, verified in early August 2026. Both pages carry the note "Usage Limits (Subject to Change)" — treat this table, and every number in this article, the same way.
I've spent the better part of a year running NotebookLM notebooks past their stated limits on purpose — splitting a 900-page dissertation to find exactly where the source cap actually bites, watching what happens when a shared team notebook blows past its daily chat quota mid-meeting, testing whether a scanned PDF really fails silently or just badly. The numbers below are what I've verified against Google's own documentation, cross-checked against real usage. Where Google hasn't published a number — and there are more of those gaps than you'd expect from a product this widely covered — I say so directly instead of repeating whatever figure is circulating on the fifth search result.
If you're brand new to the product, start with the Complete NotebookLM Guide instead — this article assumes you already know what a notebook and a source are, and goes deep specifically on where the walls are. If you're trying to decide whether a limit is worth paying to raise, see NotebookLM Pricing, which covers the dollar side; this article stays focused on the numbers themselves.
It's worth understanding why these ceilings exist before treating them as arbitrary friction, because it changes how you plan around them.
Every source you add to a notebook has to be read, chunked, and indexed before the AI can answer questions about it — that's real compute cost, on every single upload, whether or not you ever ask a question about that source again. A free product with no limits on that process is not a sustainable product; someone uploading unlimited 500,000-word documents into unlimited notebooks would cost Google real money with zero revenue attached. The tiered source-and-notebook structure is a fairly standard freemium shape: generous enough that casual use never hits a wall, restrictive enough that heavy use has a reason to pay.
The per-source size cap (500,000 words, 200MB) is a different kind of limit — it's not primarily about cost, it's about what a single grounded answer can coherently draw from. NotebookLM's whole design premise is that answers are traceable to specific passages in specific sources. A source so large that no single citation could meaningfully point to "the relevant part" undermines that premise. This is also the reason upgrading a plan doesn't raise the per-source cap: it's a design constraint tied to how citation and retrieval work, not a monetization lever like the sources-per-notebook count is.
The daily quotas (chats, Audio Overviews, and the rest) exist for the more familiar reason any AI product rate-limits usage: inference isn't free, and unrestricted access on a free tier invites both cost blowouts and abuse.
This is the most complete version of Google's own plan-limits table we could assemble — most articles covering this stop at sources and notebooks. Google's documentation actually publishes limits for eight separate quotas per plan:
A few things worth noticing that aren't obvious just from scanning the numbers:
{/ TODO: Screenshot of the official Google plan-comparison table for visual reference /}
The notebook ceiling (100 on Free up to 500 on Pro/Ultra) is an account-wide cap, separate from anything that happens inside an individual notebook. Hit it, and creating a new notebook requires deleting or — if you're using a Chrome extension that adds archiving, like Sourclip — archiving an existing one first; there's no documented way to request a one-off increase.
In practice, almost nobody hits this ceiling through normal use. The people who do are usually running one notebook per client, per course, or per small project over a long period without ever cleaning up finished ones. If that's your pattern, the actual fix isn't more notebooks — it's an organizational system that lets you retire or consolidate old ones, which is a separate problem from the limit itself. See organizing NotebookLM notebooks at scale for that.
This is the limit most people mean when they say "NotebookLM's source limit," and it's the one with the most search demand behind it. Free gives you 50 sources in a single notebook; Plus doubles it to 100; Pro triples that to 300; and the two Ultra tiers go to 500 and 600.
The part that trips people up: this is a per-notebook number, not a per-account one. A free account with 100 notebooks at 50 sources each has a theoretical account-wide capacity of 5,000 sources — the wall you actually hit day to day is almost never "I can't add any more sources anywhere," it's "I can't add any more sources to this specific notebook." The fix for that is usually splitting a project across two notebooks with a shared context note explaining the split, not upgrading — though if you're regularly filling 50-source notebooks and need everything visible to the AI in one place, that's exactly the signal that a higher tier (or Sourclip's Collections feature for keeping split notebooks organized as one logical group) is worth it.
Every source, on every plan, is capped at 500,000 words or 200MB, whichever limit you hit first for that particular file. This is worth repeating because it's the single most consistently misunderstood limit in the whole product: it does not change with your subscription tier. Free and the top Ultra plan have the identical per-source ceiling. What Ultra buys you is more sources, not bigger individual sources.
Google's own documentation speaks in words and megabytes, not characters — with one exception (Google Sheets, covered below, which uses a 100,000-token limit instead). If you're trying to reverse-engineer a character count from the 500,000-word figure, there's no official conversion published; word count is the number that governs almost everything.
PDFs inherit the general 500,000-word / 200MB ceiling, plus one PDF-specific catch that isn't really a "limit" in the numeric sense but behaves like one in practice: NotebookLM only reads a PDF's text layer. A scanned or photographed document has no text layer — it's an image of text, not text — so there's nothing for the system to index, and Google's own troubleshooting guidance confirms sources without readable text won't produce useful answers. This isn't a size problem; a 2MB scanned PDF fails the same way a 190MB one does.
The fix is running OCR before upload — Google Drive's "open as Google Doc" trick does this automatically and free, or use a dedicated OCR tool for better accuracy on poor-quality scans. For documents that hit the actual size or word ceiling (a full book, a dissertation, a bundled multi-report PDF), splitting is the only real fix, and we've written a full breakdown of that specific problem: handling large PDFs and long documents in NotebookLM, including a free, browser-based Sourclip PDF Splitter that splits by page range without uploading your document anywhere.
{/ TODO: Diagram showing scanned PDF (no text layer) vs. OCR'd PDF (text layer) side by side /}
The 500,000-word / 200MB ceiling is the default, but several source types have their own additional rules layered on top. Here's what Google documents for each.
NotebookLM scrapes only the text content of a webpage — no images, no embedded videos, no content from nested pages or linked articles. Paywalled pages aren't supported at all; if the page requires a login or subscription to view the full text, the import will only capture whatever's visible without one.
If you regularly need the full content of a page — including material a simple scrape misses, or you want a clean copy to review before it becomes a source — running the URL through a converter first and pasting the result as a text source can produce a more complete, more predictable source than the built-in importer. Sourclip's Webpage to Markdown tool does exactly that conversion for free in the browser.
NotebookLM imports a video's caption transcript, not the video file — which is why there's no hard duration limit in the way you'd expect. The actual constraint is that the transcript itself can't exceed 500,000 words, which for the overwhelming majority of videos (even multi-hour ones) isn't a real ceiling. What does matter:
Audio sources (MP3, WAV, and other common formats) are transcribed automatically on import, with support for 40+ languages. Audio with no speech in it — ambient recordings, music without vocals — isn't supported, for the same reason a silent video isn't: there's nothing to transcribe.
Docs behave like a standard text source subject to the usual 500,000-word ceiling, with one meaningful behavioral difference from a plain upload: sources imported from Google Drive stay live-synced. Google's documentation states these sources auto-update every few minutes to reflect changes in the original file — you don't need to re-upload after editing a Doc that's already a source. Two caveats worth knowing: NotebookLM does not import footnotes or comments from Google files, and it can't edit or delete your original file in Drive — the relationship is strictly read-only in that direction.
Google Slides has its own separate cap layered on top of the general limit: up to 100 slides per source. A deck larger than that needs to be split or trimmed before it'll import cleanly.
Sheets is the one source type that doesn't use the word-count system at all — it's governed by a 100,000-token limit instead. This is a meaningfully different unit than the 500,000-word cap everything else uses, and it's easy to assume a large spreadsheet has the same headroom as a large document when it doesn't. If you're importing a sizable Sheet and it's failing or truncating, the token limit — not the word limit — is almost certainly why.
Images (JPG, PNG, and other common formats) are supported as sources and fall under the same general 200MB file-size ceiling as any other upload. There's no separate, documented "image count" limit beyond the standard sources-per-notebook cap — an image simply counts as one source, the same as a PDF or a webpage would.
Directly pasted text and imported chat transcripts are treated as regular text sources, subject to the same 500,000-word ceiling as everything else. One practical wrinkle here: text copied from PDFs, ChatGPT exports, or other AI tools often carries formatting artifacts — stray line breaks, repeated headers, broken markdown — that don't cause an import failure but do make the source noisier for the AI to work with. Running messy pasted text through a cleanup pass before adding it as a source — Sourclip's Markdown Cleaner is a free option for this — tends to produce more reliable answers than pasting the raw export directly.
Beyond the storage-style limits (sources, notebooks), NotebookLM enforces daily generation quotas across chats, Audio Overviews, Video Overviews, Reports, Flashcards, Quizzes, and Mind Maps — all detailed in the full table above. The mechanics worth understanding:
If you're on a shared or team account and multiple people draw from the same daily pool, this is worth planning around explicitly — see organizing NotebookLM for teams for how to structure that.
You'll see a specific number repeated across a lot of NotebookLM coverage: an approximate 25 million words as the combined capacity across all sources in one notebook. We went looking for where this comes from, and we could not find it published anywhere on Google's own support pages — not in the plan-limits table, not in the sources FAQ, not in any official documentation we could locate.
It also doesn't hold up well against the numbers Google does publish. The top Ultra tier allows 600 sources per notebook at up to 500,000 words each — a theoretical maximum of 300 million words, more than ten times the commonly cited 25-million figure. That gap doesn't necessarily mean the 25-million number is fabricated (there could be an unpublished aggregate indexing ceiling that kicks in well before the per-source math maxes out), but it does mean it's not something we can verify, source, or responsibly repeat as fact.
Our honest recommendation: don't plan a large research project around a specific total-word ceiling that Google hasn't confirmed. If you're building a very large, many-source notebook, watch for degraded response quality (covered next) as your practical early-warning signal rather than a word count you're counting down from.
This section is softer than everything above it, on purpose — it's describing observed behavior, not a published spec, and we want that distinction to be obvious rather than blended in with the documented numbers.
Multiple independent reports (and our own experience running large notebooks) describe response quality becoming noticeably more generic as a notebook's source count climbs into the several-dozen range on complex, cross-cutting questions — not because of a hard cutoff, but because a broader source pool gives the model a wider space to draw a general answer from instead of a specific, well-cited one. Some coverage attributes this to context-window mechanics — reportedly, NotebookLM chat now runs on Gemini's full 1-million-token context window across all plans, which is a meaningfully large working memory but still finite once a notebook's total source volume grows large enough.
The practical takeaway, regardless of the exact mechanism: if a large notebook's answers start feeling vague or generic rather than sharply cited, that's a signal to narrow your question, pin the specific sources most relevant to it, or split the notebook by sub-topic — not necessarily a sign you've hit an official ceiling. See NotebookLM research workflows for techniques that work with this behavior rather than against it.
NotebookLM lets you share a notebook with other people as Viewer or Editor collaborators. We could not find a specific, documented cap on the number of collaborators you can add to a single notebook — the available evidence suggests it's not a tightly restricted number the way sources-per-notebook is, but "not tightly restricted" and "officially unlimited" aren't the same claim, and Google doesn't appear to publish one directly. If you're planning a notebook with a large number of collaborators (a big class, a large team), it's worth testing with a smaller group first rather than assuming there's no ceiling at all.
Public notebooks — the option to publish a notebook for anyone with the link to view — are a separate feature from private collaborator sharing, with their own considerations around what's visible to a public audience; that's a large enough topic to deserve separate treatment rather than a paragraph here.
To consolidate everything above into one clear statement: paid tiers raise counts and quotas — sources per notebook, notebooks per account, daily chats, daily generations of every artifact type. Paid tiers do not raise the size ceiling on any individual source (500,000 words / 200MB, identical everywhere), and they don't change the fundamental behavior of any source type — OCR still isn't automatic on Ultra, YouTube videos still need public captions on Ultra, Sheets still uses the 100k-token limit on Ultra.
If your specific problem is a single oversized document, no plan fixes it — see the PDF section above for the actual fix. If your problem is running out of room across many sources or many notebooks, that's exactly what upgrading solves. For the full cost breakdown of each tier, see NotebookLM Pricing (2026) — this article intentionally doesn't repeat that pricing detail here.
Get clean captures, workspace management, reusable prompts, and easy exports.
Add Sourclip to ChromeFor the full product walkthrough, see the Complete NotebookLM Guide. For what the rebrand did and didn't change, see NotebookLM Is Now Gemini Notebook. For the cost of raising any of these limits, see NotebookLM Pricing (2026).