# NotebookLM Limits: Sources, File Sizes, and Words (2026 Guide)

Google NotebookLM limits define operational boundaries for AI research, capping free notebooks at 50 sources, 200MB per file, and 500,000 words per document. While premium tiers expand NotebookLM limits up to 600 sources per notebook, the per-source size and 500,000 words ceilings remain fixed across every plan. Understanding these thresholds helps research teams avoid ingestion truncation and structure large-scale document collections effectively.

Source: https://fast.io/resources/notebooklm-limits/
Author: [Derek Labian](https://fast.io/authors/derek-labian/)
Last reviewed: 2026-09-22

## What Are the Current Google NotebookLM Limits?

Google limits free Standard NotebookLM accounts to 50 sources per notebook and 500,000 words per source as of September 2026. For research teams, analysts, and developers organizing large document libraries, these parameters define the operational boundary between what fits directly into Google's interface and what requires external architecture.

NotebookLM limits define the boundaries of Google's AI research assistant, including a 50-source notebook cap, 200MB and 500,000 words per source, and monthly Audio Overview generation quotas.

Google rebranded NotebookLM to Gemini Notebook in July 2026 to consolidate its AI tooling under the Gemini umbrella. In September 2026, Google introduced a compute-based usage system that refreshes AI availability across rolling five-hour intervals. While the branding and interface continue to adapt, the underlying document ingestion boundaries remain rigid.

The following table summarizes the baseline limits across Google's published account tiers:

| Plan Tier | Sources per Notebook | Local File Size Limit | Word Limit per Source | Audio Overviews Quota | Date Checked |
|---|---|---|---|---|---|
| Standard (Free) | 50 | 200MB | 500,000 words | 3 per day | 2026-09-22 |
| Plus ($4.99/mo) | 100 | 200MB | 500,000 words | 6 per day | 2026-09-22 |
| Pro ($19.99/mo) | 300 | 200MB | 500,000 words | 20 per day | 2026-09-22 |
| Ultra 20 TB ($99.99/mo) | 500 | 200MB | 500,000 words | 100 per day | 2026-09-22 |
| Ultra 30 TB ($199.99/mo) | 600 | 200MB | 500,000 words | 200 per day | 2026-09-22 |

These figures outline two distinct operational thresholds. The first is container capacity, which controls how many discrete items can reside within a single research project. The second is item density, which determines how heavy an individual file can be before the ingestion parser rejects it.

On a Standard account, having 50 maximum sources per notebook at 500,000 words per source yields a theoretical ceiling of 25 million words per notebook. In practice, researchers rarely hit the theoretical 25 million words limit across notebook sources through text volume alone. The practical failure point occurs when a team reaches Google NotebookLM source limits or attempts local uploads exceeding the 200MB limit for each file.

### Document Format Rules and Ingestion Ceilings

The 200MB and 500,000 words limits on NotebookLM source uploads apply differently depending on the structure and format of each file. Because NotebookLM parses text during ingestion, document composition dictates whether an upload succeeds.

* **PDF Documents:** Native text PDFs containing hundreds of pages generally process without friction. In contrast, scanned archival files, legal briefs, and historical reports contain raster image layers that expand file size quickly. NotebookLM limits each local upload to 200MB, rejecting oversized files before text extraction starts. Password-protected or copy-protected PDFs fail immediately across all plans.
* **Google Drive Files:** Linking files directly from Google Drive establishes a connection that checks for file updates periodically. However, specialized constraints apply. Google Slides imports into a notebook are limited to 100 slides per presentation source. Google Sheets documents are evaluated up to a ceiling of 100,000 tokens, meaning dense financial models or extensive datasets truncate silently. Footnotes and reader comments in Google Docs are excluded from ingestion.
* **Web Pages and URLs:** Pasting a public web URL extracts only the visible HTML text. Paywalled sites, complex JavaScript web applications, embedded video players, and nested subpages cannot be imported through a single URL entry.
* **YouTube Video Links:** YouTube imports extract published caption tracks rather than raw audio or video streams. If a video features creator-uploaded subtitles or completed auto-captions, NotebookLM imports the transcript text. Video length is not capped, provided the total transcript remains below 500,000 words. Videos uploaded within the past 72 hours frequently fail because auto-caption processing has not fully propagated across Google's network.
* **Audio Recordings:** Supported audio formats include MP3, WAV, AAC, M4A, and OGG. Google processes audio files on remote servers to generate plain-text transcripts. Uploads lacking clear speech or tracks obscured by heavy background interference fail during transcription.

## How Do NotebookLM Limits Compare Across Free and Paid Tiers?

In mid-2026, Google aligned NotebookLM quotas with its unified Google AI consumer subscriptions. Upgrading to a paid plan unlocks higher notebook counts, expanded source allowances, and larger daily query budgets. However, upgrading does not alter the fundamental per-source ceilings.

The breakdown below details the published operational capacities across consumer subscription tiers:

| Parameter | Standard (Free) | Plus ($4.99/mo) | Pro ($19.99/mo) | Ultra 20 TB ($99.99/mo) | Ultra 30 TB ($199.99/mo) |
|---|---|---|---|---|---|
| Notebooks per User | 100 | 200 | 500 | 500 | 500 |
| Sources per Notebook | 50 | 100 | 300 | 500 | 600 |
| Local Upload Limit | 200MB | 200MB | 200MB | 200MB | 200MB |
| Word Cap per Source | 500,000 words | 500,000 words | 500,000 words | 500,000 words | 500,000 words |
| Daily Chat Queries | 50 | 200 | 500 | 2,500 | 5,000 |
| Audio Overviews / Day | 3 | 6 | 20 | 100 | 200 |
| Video Overviews / Day | 3 | 6 | 20 (2 cinematic) | 100 (10 cinematic) | 200 (20 cinematic) |
| Deep Research Reports | 10 per month | 3 per day | 20 per day | 75 per day | 200 per day |

The central insight from this structure is that paid subscriptions solve volume constraints rather than individual document size constraints. Moving from Standard to Pro increases your source slots from 50 to 300 items per notebook. Yet if a team possesses an uncompressed scan exceeding the 200MB local upload limit or an export holding over 500,000 words per source, no tier permits direct ingestion.

Collaborator rules introduce another practical restriction. Collaborating on a shared notebook does not change the source limit for any collaborator. If an Ultra subscriber builds a notebook containing 550 sources and invites a Standard user, the collaborator can read and query all 550 sources. However, the invited collaborator cannot add new sources beyond the existing allocation, and each query draws against that collaborator's personal usage allowance.

### Compute-Based Usage and the Five-Hour Refresh Cycle

Google's September 2026 update introduced compute-based AI metering on top of published daily quotas. Instead of evaluating queries strictly by message count, the system calculates usage based on computational load.

Several technical variables influence compute consumption:

* **Prompt Complexity:** Open-ended requests that require comparative cross-referencing consume more compute budget than targeted factual searches.
* **Active Source Set:** Directing the model to read across 50 active sources demands more processing capacity than querying a single document.
* **Conversation Depth:** Extensive chat histories carrying dozens of contextual exchanges draw down the compute allocation more rapidly.
* **Output Artifacts:** Creating multimedia summaries, mind maps, or slide decks requires higher compute allocations than standard conversational answers.

Under this model, compute availability refreshes across rolling five-hour intervals until the account reaches its weekly boundary. If an intensive research session exhausts your compute allowance, the interface may suggest lighter generation formats or prompt you to wait for the next five-hour refresh window. Published daily quotas (such as 50 chats per day on Standard) reset after 24 hours, while monthly allowances reset after 30 days. Fixed storage limits, including notebook and source counts, never reset with time.

## Why Massive Document Collections Collide with Upload Ceilings

Direct-upload AI tools treat document storage as a prompt-attachment pipeline. Files are uploaded into a closed container, stripped down to raw text, and passed into an inference session. While functional for reviewing a single book or several whitepapers, this pattern collapses when applied to enterprise knowledge bases, legal discovery, or extensive technical archives.

The initial breakdown stems from scan bloat. Legal filings, court records, property deeds, and technical schematics often arrive as scanned image files. Even with efficient PDF compression, an uncompressed multi-volume binder easily exceeds 200MB while containing only a few thousand words of actual text. Because the upload gate evaluates total file weight on disk, researchers spend hours segmenting documents into arbitrary pieces simply to pass ingestion filters.

The second bottleneck involves word truncation. When an individual file exceeds 500,000 words, or when a spreadsheet surpasses 100,000 tokens, the ingestion engine discards the trailing content. Crucially, this truncation often occurs without explicit warnings in the chat interface. A researcher querying a comprehensive contract repository may receive confident answers that completely omit clauses located in the truncated appendices.

The third operational constraint is notebook isolation. In NotebookLM, each notebook operates as an independent silo. You cannot execute a unified query spanning Project A (Corporate Governance) and Project B (Tax Compliance). To analyze both areas simultaneously, you must upload duplicate copies of your sources into a third notebook. This practice rapidly exhausts your 100-notebook account capacity and fractures document version management across your team.

### Context Window Saturation and Retrieval Degradation

The source barriers in NotebookLM reflect broader architectural limits across conversational AI tools. In Claude Projects, individual uploaded files face strict size ceilings, and while project file count is technically unrestricted, the aggregate content must fit entirely within Claude's active context window. Attaching dozens of complete files directly to a project prompt quickly saturates available context space.

Even with long-context architectures like Gemini 1.5 Pro, packing dozens of massive sources into active inference degrades output quality. This behavior is recognized in AI evaluation literature as the lost-in-the-middle problem. Large language models do not distribute attention uniformly across millions of tokens. When 50 dense sources sit in active context, models exhibit higher retrieval latency, occasional hallucinations, and an increased likelihood of overlooking specific details buried in the middle of long chapters.

Stuffing raw document collections directly into model context windows is analytically fragile. Modern research systems solve this by decoupling persistent storage from inference: store your entire corpus in an external, indexed workspace, and retrieve only the relevant passages required to answer each specific query.

## How to Structure Large Research Repositories Using External Indexing and MCP

Overcoming the 50-source notebook cap does not require waiting for AI vendors to lift their upload limits. The established engineering pattern separates document persistence from the conversational client. Instead of pushing whole files into closed containers, teams store their core archives in an intelligent workspace like [Fast.io Workspaces](/product/workspaces/) and connect their preferred assistant through the Model Context Protocol (MCP).

This architecture functions across three distinct layers:

**1. Centralized Workspace Persistence**

Teams store multi-gigabyte document collections in shared, organization-owned workspaces. Files can be added using chunked uploads, which process large files smoothly without browser timeout errors or artificial size boundaries. Teams can also use cloud import to pull existing document libraries from Google Drive, Dropbox, Box, or OneDrive. Google Drive imports files directly today with automated sync scheduled for release, while Dropbox, Box, and OneDrive support scheduled synchronization.

**2. Intelligence Mode and Hybrid Indexing**

When documents enter the workspace, enabling Intelligence Mode activates automated indexing for retrieval-augmented generation (RAG). The platform parses PDFs, text documents, spreadsheets, presentations, and code files, building a hybrid search index that combines full-text keyword retrieval with semantic vector search. The workspace maintains this searchable index continuously without requiring external vector databases, custom chunking scripts, or embedding pipelines. When a search runs, the system returns precise excerpts backed by verified source citations.

**3. Remote MCP Integration**

Rather than uploading full documents to each AI vendor, you connect your assistant directly to the workspace using Fast.io's remote MCP endpoint at `https://mcp.fast.io/mcp`. When your AI assistant needs factual context, it queries the workspace index using MCP tools, retrieves relevant text snippets, and injects only those targeted passages into its active context window. This architecture leaves Google's and Anthropic's vendor-specific upload limits untouched; it simply eliminates the need to upload files into those containers in the first place.

### Connecting AI Assistants to Workspaces via MCP

Fast.io provides remote MCP tooling over Streamable HTTP at `https://mcp.fast.io/mcp` and legacy Server-Sent Events (SSE) at `https://mcp.fast.io/sse`. To connect desktop assistants or autonomous agents, point your client configuration to `https://mcp.fast.io/mcp/key` and supply an account API key in the authorization header.

For example, connecting an MCP client like Claude Desktop requires adding the remote endpoint to your configuration file:

```json
{
  "mcpServers": {
    "fastio": {
      "url": "https://mcp.fast.io/mcp/key",
      "headers": {
        "Authorization": "Bearer YOUR_FASTIO_API_KEY"
      }
    }
  }
}
```

Once connected, your assistant can search across thousands of indexed documents instantly. When you prompt the assistant to analyze contract liabilities across 80 vendor agreements, the model queries the workspace index, extracts the relevant clauses, and drafts a comprehensive answer with complete document attribution.

This decoupled architecture provides three decisive operational advantages:

* **Unrestricted Corpus Scale:** Your research repository can expand to thousands of files without hitting a 50-source or 600-source container gate.
* **Uncluttered Context Windows:** Because the assistant ingests only the relevant paragraphs rather than 50 entire PDF files, inference remains fast, precise, and free from attention dilution.
* **Per-File Version History:** The workspace preserves per-file version history and an append-only audit trail. When documents change, the search index refreshes automatically, ensuring all human collaborators and connected assistants work from current information. Teams exploring [Fast.io for AI agents](/storage-for-agents/) can get started immediately with indexed document workspaces.

## Practical Workarounds for Hitting NotebookLM File and Source Caps

When your immediate workflow requires using NotebookLM directly, several practical preprocessing strategies can help you optimize documents to fit within 200MB and 500,000-word thresholds.

**1. Split Oversized PDFs Using Command-Line Tools**

When a single regulatory filing, transcript binder, or academic text exceeds 200MB, segmenting the file into sequential chapters or topical sections allows you to upload each part as a discrete source.

On macOS and Linux, you can split PDF documents cleanly without quality degradation using `qpdf`:

```bash
qpdf input-large-corpus.pdf --pages . 1-150 -- part-1.pdf
qpdf input-large-corpus.pdf --pages . 151-300 -- part-2.pdf
```

**2. Downsample Raster Graphics in Scanned Files**

Excessive PDF file size is usually caused by uncompressed high-resolution page scans rather than raw text density. Downsampling embedded bitmap scans to 150 DPI provides sharp, legible text for optical character recognition while reducing file size substantially.

You can compress image-heavy PDFs using Ghostscript:

```bash
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=compressed-document.pdf input-oversized-scan.pdf
```

This configuration recompresses embedded images to a standard reading resolution, bringing heavy scans comfortably below the NotebookLM 200MB local upload limit for each source.

**3. Convert Media Files to Text Transcripts Prior to Upload**

Uploading raw audio recordings to NotebookLM consumes substantial bandwidth and introduces transcription delay. For long hearings, interviews, or lectures, transcribe the audio locally using open-source speech models such as Whisper before uploading. A recorded discussion that takes hundreds of megabytes in audio format compresses down to a lightweight text file that uploads in seconds while consuming minimal word capacity.

**4. Consolidate Short Related Documents**

If your research involves dozens of brief memos, field notes, or email threads, uploading each item individually will rapidly consume your 50-source allocation. Merging related notes into unified Markdown or plain-text files organized by topic or date allows you to store substantial content within a single source slot.

**5. Extract Tabular Data into Structured Metadata Views**

Large spreadsheets and dense CSV files frequently exceed token limits and perform poorly in conversational chat prompts. For document sets containing hundreds of invoices, leases, or technical spec sheets, use [Metadata Views](/product/document-data-extraction/) inside your workspace.

Metadata Views convert unstructured files into a typed, searchable database. You describe the desired fields in natural language, and the system constructs a schema supporting Text, Integer, Decimal, Boolean, URL, JSON, and Date & Time types. Connected assistants can query structured values, filter by parameters, and aggregate findings via MCP without exhausting document upload limits or cluttering model context windows.

## Frequently asked questions

### What are the limits on NotebookLM?

Google limits free Standard NotebookLM accounts to 50 sources per notebook, 200MB per file upload, and 500,000 words per source. Premium Google AI tiers raise source caps up to 600 items per notebook, but the per-source file size and word ceilings remain identical across all plans. AI usage is metered across rolling five-hour compute windows alongside published daily query quotas.

### How many files can you upload to NotebookLM?

On the free Standard plan, you can upload up to 50 sources per notebook and maintain up to 100 notebooks per account. Paid tiers expand these limits: Google AI Plus supports 100 sources across 200 notebooks, Google AI Pro allows 300 sources across 500 notebooks, and Google AI Ultra supports up to 600 sources across 500 notebooks.

### Is there a word limit for NotebookLM?

Yes. Each individual source is capped at 500,000 words across all subscription tiers. On a Standard notebook with 50 sources, this provides a theoretical capacity of 25 million words. Additionally, Google Sheets imports are evaluated up to a ceiling of 100,000 tokens, causing larger spreadsheets to truncate during ingestion.

### Does NotebookLM have a file size limit for PDFs?

Every local file upload in NotebookLM, including PDFs, is subject to a strict 200MB limit per source. NotebookLM enforces this limit regardless of page count. Scanned documents containing uncompressed image layers frequently breach this threshold and must be compressed or split before upload.

### How do you bypass NotebookLM limits?

For individual oversized files, you can bypass upload limits by splitting PDFs using tools like qpdf, downsampling scanned images with Ghostscript, or converting audio into text transcripts before uploading. For multi-hundred document collections, teams bypass source limits by storing files in an intelligent cloud workspace like Fast.io and querying the indexed corpus via MCP tools.

### Does sharing a notebook increase its source capacity?

No. In Google's official documentation, collaborating on a shared notebook does not change the source limit for any collaborator. An invited collaborator can view and query existing sources within the owner's plan allowance, but cannot add sources beyond the notebook cap.

## Sources

- [Google: Gemini Notebook Help - Add or discover new sources for your notebook](https://support.google.com/gemininotebook/answer/16215270?hl=en) — Google caps each Gemini Notebook source at 500,000 words, or 200MB for uploaded files, on every plan tier.
- [Google: Gemini Notebook Help - Upgrade Gemini Notebook](https://support.google.com/gemininotebook/answer/16213268?hl=en) — Gemini Notebook allows 50 sources per notebook on Standard, rising to 100 on Plus, 300 on Pro, 500 on Ultra 20 TB and 600 on Ultra 30 TB.
- [Google: Google AI Plans](https://one.google.com/about/google-ai-plans/) — Google prices Google AI Plus at $4.99 per month and Google AI Pro at $19.99 per month, with the two Ultra tiers at $99.99 and $199.99.
- [Google: Gemini Notebook Help - Upgrade Gemini Notebook](https://support.google.com/gemininotebook/answer/16213268?hl=en) — Collaborating on a shared notebook does not change the source limit for any collaborator.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server at https://mcp.fast.io/mcp, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli.